Re: nnmail-split-fancy-match-partial-words

[Reiner Steib <reinersteib+gmane@imap.cc>]

On Fri, Mar 03 2006, Katsumi Yamaoka wrote:

>>>>>> In <slpzq2t8.fsf@esemetz.metz.supelec.fr>
>>>>>>	Fabrice Popineau wrote:
>
>> Id' like to draw attention on the following point. I have a rather long
>> nnmail-split-fancy list. I had this split rule :
>
>> ("subject" "\\[ce\\]" foo.ce)
[...]
>> I ended up in crudely patching nnmail-split-it in nnmail.el but that's
>> defintely not a clean answer to the problem. Maybe that's a limitation
>> of regexp/syntax tables after all.
>
>> -	(when nnmail-split-fancy-match-partial-words
>> +	(when
>> +	    (or nnmail-split-fancy-match-partial-words
>> +		;; FP: if there are backets in the sequence, don't surround with <..>
>> +		(string-match "\\[.*\\]" value))
>
> Thank you for the patch, but it seems to be better to use
> "\\\\\\[.*\\\\\\]" because "\\[.*\\]" matches "[0-9]", "[a-z]",
> etc.  Does anyone notice other adverse effects?

I'd rather not put such a special treatment into the code _if_ we can
avoid it.  The current behavior is quite clearly documented[1].

For "@foo" there is a similar problem, which can be solved by adding
".*":

,----
| ELISP> (string-match (concat "\\<" "@foo\\.bar\\.invalid" "\\>")
| 		      "someone@foo.bar.invalid")
| nil
| ELISP> (string-match (concat "\\<" ".*@foo\\.bar\\.invalid" "\\>")
| 		      "someone@foo.bar.invalid")
| 0
`----

But the ".*" trick doesn't work in Fabrice's example:

,----
| ELISP> (string-match "\\<.*\\[ce\\]" "[ce] blu")
| nil
`----

Hm, isn't there a simple trick for this one, too?

Or we could add a forth element specifying the partial-words behavior
in the split rule:

  ("subject" ".*\\[ce\\].*" foo.ce t)

>> BTW, all occurences of set-file-modes should be replaced with
>> gnus-set-file-modes for windows users'sake (at least under xemacs).
>
>> -    (set-file-modes filename nnmail-default-file-modes)))
>> +    (gnus-set-file-modes filename nnmail-default-file-modes)))
>
> I think it should be applied anyway.  mail-source.el and
> mm-decode.el also use set-file-modes.
>
>> I'm using xemacs 21.5.b21 under native windows for what it worth.
>
> I will install those changes if no one comments within a couple
> of days.

I didn't investigate the callers, but maybe it *should* give an error
if the modes cannot be set appropriately.  (Shouldn't the respective
(X)Emacs function care for those file system / operation system
details?)

*time passes* ...  After reading the discussion
<http://thread.gmane.org/gmane.emacs.gnus.general/57528>, I think we
should change `gnus-set-file-modes' as follows...

;; See http://thread.gmane.org/gmane.emacs.gnus.general/57528
(defcustom gnus-ignore-set-file-modes-errors nil
  "Ignore errors when calling `set-file-modes'."
  :type boolean
  :version "23.0" ;; No Gnus
  :group 'gnus-various)

(defun gnus-set-file-modes (filename mode)
  "Wrapper for set-file-modes."
  (if gnus-ignore-set-file-modes-errors
      (ignore-errors (set-file-modes filename mode))
    (set-file-modes filename mode)))

Bye, Reiner.

[1]
,----[ (info "(gnus)Fancy Mail Splitting") ]
|    In these splits, FIELD must match a complete field name.  VALUE must
| match a complete word according to the fundamental mode syntax table.
| You can use `.*' in the regexps to match partial field names or words.
| In other words, all VALUE's are wrapped in `\<' and `\>' pairs.
|
| [...]
| 
|    `nnmail-split-fancy-match-partial-words' controls whether partial
| words are matched during fancy splitting.
| 
|    Normally, regular expressions given in `nnmail-split-fancy' are
| implicitly surrounded by `\<...\>' markers, which are word delimiters.
| If this variable is true, they are not implicitly surrounded by
| anything.
`----
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/