nnmail-fancy-split failing

[Seb]

Hi,

I'd like to send messages containing the string "string", possibly
capitalized and surrounded by any other characters, to end up in group
"stringGroup", so I included the following rule:

(setq spam-split-group "Spam"
nnmail-split-methods 'nnmail-split-fancy
nnmail-split-fancy
'(| (: nnmail-split-fancy-with-parent)
("subject" ".*[Ss]tring.*" "diveMove")
(: spam-split)
"Incoming"))

but such messages are invariably ending up in "Incoming". Any idea what
is wrong with this `nnmail-split-fancy' specification? Thanks in advance.

Cheers,

--
Seb

[Katsumi Yamaoka]

If the raw subject line in such a mail is encoded like this

Subject: =?iso-8859-1?b?c3RyaW5n?=

(type `C-u g' in the summary buffer to see it)

what you look for is:

(setq nnmail-mail-splitting-decodes t)

,---- (info "(gnus)Splitting Mail") ----
| By default, splitting does not decode headers, so you can not match
| on non-ASCII strings. But it is useful if you want to match articles
| based on the raw header data. To enable it, set the
| `nnmail-mail-splitting-decodes' variable to a non-`nil' value.
`----

Maybe this is not for you:

(setq nnmail-split-fancy-match-partial-words t)

But you can make your regexps simple with it.

,---- (info "(gnus)Fancy Mail Splitting") ----
| Normally, VALUE in these splits must match a complete _word_
| according to the fundamental mode syntax table. In other words, all
| VALUE's will be implicitly surrounded by `\<...\>' markers, which are
| word delimiters. Therefore, if you use the following split, for
| example,
|
| (any "joe" "joemail")
|
| messages sent from `joed...@foo.org' will normally not be filed in
| `joemail'. If you want to alter this behavior, you can use any of the
| following three ways:
|
| 1. You can set the `nnmail-split-fancy-match-partial-words' variable
| to non-`nil' in order to ignore word boundaries and instead the
| match becomes more like a grep. This variable controls whether
| partial words are matched during fancy splitting. The default
| value is `nil'.
|
| Note that it influences all VALUE's in your split rules.
|
| 2. VALUE beginning with `.*' ignores word boundaries in front of a
| word. Similarly, if VALUE ends with `.*', word boundaries in the
| rear of a word will be ignored. For example, the VALUE
| `"@example\\.com"' does not match `f...@example.com' but
| `".*@example\\.com"' does.
|
| 3. ...
`----

[Seb]

On Mon, 26 Oct 2009 16:26:16 +0900,
Katsumi Yamaoka <yam...@jpl.org> wrote:

[...]

> If the raw subject line in such a mail is encoded like this

> Subject: =?iso-8859-1?b?c3RyaW5n?=

> (type `C-u g' in the summary buffer to see it)

> what you look for is:

> (setq nnmail-mail-splitting-decodes t)

Indeed, the subject was encoded like that (UTF-8 though), so that is
exactly what I needed. Thanks for the suggestion Katsumi.

Any danger in making that a default?

--
Seb

[Ted Zlatanov]

On Mon, 26 Oct 2009 09:25:27 -0500 Seb <spl...@gmail.com> wrote:

S> On Mon, 26 Oct 2009 16:26:16 +0900,

S> Katsumi Yamaoka <yam...@jpl.org> wrote:
>> If the raw subject line in such a mail is encoded like this

>> Subject: =?iso-8859-1?b?c3RyaW5n?=

>> what you look for is:

>> (setq nnmail-mail-splitting-decodes t)

S> Indeed, the subject was encoded like that (UTF-8 though), so that is
S> exactly what I needed. Thanks for the suggestion Katsumi.

S> Any danger in making that a default?

I would like that too. I see little danger there, mail splitting is
slow for other reasons (backend spooling, registry lookups, etc.) so an
extra decode step would not be too bad, especially if it's optimized to
happen only when necessary.

Ted