nnmail-split-fancy-match-partial-words

nnmail-split-fancy-match-partial-words

[Fabrice Popineau]

Hi,

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)

that was not working and I had much trouble in finding why. In fact,
that is because of interaction between
nnmail-split-fancy-match-partial-words and the status of [] that do not
belong to words in the default syntax table. While I'd like to retain
the default nil value for matching partial words, I'd expect also that
any regexp I put in the fancy split rule is taken for what it is.

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.

BTW, all occurences of set-file-modes should be replaced with
gnus-set-file-modes for windows users'sake (at least under xemacs).

I'm using xemacs 21.5.b21 under native windows for what it worth.

--- nnmail.el	2006-02-01 13:51:57.000000000 +0100
+++ nnmail.el	2006-03-03 10:15:01.000000000 +0100
@@ -1436,7 +1436,10 @@
 		 (string= ".*" (substring value -2)))
 	    (setq value (substring value 0 -2)
 		  partial-rear ""))
-	(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))
 	  (setq partial-front ""
 		partial-rear ""))
 	(setq regexp (concat "^\\(\\("
@@ -1907,7 +1904,7 @@
   (let ((coding-system-for-write nnmail-file-coding-system)
 	(file-name-coding-system nnmail-pathname-coding-system))
     (write-region start end filename append visit lockname)
-    (set-file-modes filename nnmail-default-file-modes)))
+    (gnus-set-file-modes filename nnmail-default-file-modes)))
 
 ;;;
 ;;; Status functions

Best regards,

-- 
Fabrice Popineau
------------------------
e-mail:       Fabrice.Popineau@supelec.fr  |  The difference between theory 
voice-mail:   +33 (0) 387764715            |  and practice, is that
surface-mail: Supelec, 2 rue E. Belin,     |  theoretically,
	      F-57070 Metz 	           |  there is no difference !

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

[Katsumi Yamaoka]

>>>>> 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)

> that was not working and I had much trouble in finding why. In fact,
> that is because of interaction between
> nnmail-split-fancy-match-partial-words and the status of [] that do not
> belong to words in the default syntax table. While I'd like to retain
> the default nil value for matching partial words, I'd expect also that
> any regexp I put in the fancy split rule is taken for what it is.

> 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?

> 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.

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

[Reiner Steib]

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/

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

[Fabrice Popineau]

* Reiner Steib <reinersteib+gmane@imap.cc> writes:

    > On Fri, Mar 03 2006, Katsumi Yamaoka wrote:
    >>>>>>> In <slpzq2t8.fsf@esemetz.metz.supelec.fr>
    >>>>>>> Fabrice Popineau wrote:
    >>
    Fabrice>  Id' like to draw attention on the following point. I have
    Fabrice>  a rather long nnmail-split-fancy list. I had this split
    Fabrice>  rule :
    Fabrice>  
    Fabrice>  ("subject" "\\[ce\\]" foo.ce) [...]
    Fabrice>  I ended up in crudely patching nnmail-split-it in
    Fabrice>  nnmail.el but that's defintely not a clean answer to the
    Fabrice>  problem. Maybe that's a limitation of regexp/syntax tables
    Fabrice>  after all.


    Katsumi>  Thank you for the patch, but it seems to be better to use
    Katsumi>  "\\\\\\[.*\\\\\\]" because "\\[.*\\]" matches "[0-9]",
    Katsumi>  "[a-z]", etc.  Does anyone notice other adverse effects?

    Reiner>  I'd rather not put such a special treatment into the code
    Reiner>  _if_ we can avoid it.

I agree: the list of special cases might become too long.

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

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

I would like it, especially if the 4th element is optional.


Incidentally, playing with this stuff, I came with another problem. I
don't know if it is me or me and my configuration (native win32 xemacs
21.5b21) but there might be problems with
nnmail-split-fancy-syntax-table.

Namely, when I hacked nnmail.el, I byte-compiled it and restarted
xemacs. It came that none of my split-fancy rules worked anymore. I
tracked it down to nnmail-split-fancy-syntax-table not being what you would
expect because:

(make-syntax-table)
#s(char-table type syntax data ())

AKA, #'make-syntax-table  is returning  an empty  syntax table,  which  is weird. I ended  up  in
defining nnmail-split-fancy-syntax-table  as an actual  copy of the syntax table
found in the *nntpd* buffer :

--- gnus\lisp\nnmail.el 2006-03-05 21:31:19.00
00000 +0100
+++ gnus\lisp\nnmail.el   2006-03-05 21:
:31.000000000 +0100
@@ -599,10 +599,7 @@
   "List of group/article elements that say where the previous split put messa
s.")

 (defvar nnmail-split-fancy-syntax-table
-  (let ((table (make-syntax-table)))
-    ;; support the %-hack
-    (modify-syntax-entry ?\% "." table)
-    table)
+  nil
   "Syntax table used by `nnmail-split-fancy'.")

 (defvar nnmail-prepare-save-mail-hook nil
@@ -1322,6 +1319,12 @@
 (defun nnmail-split-fancy ()
   "Fancy splitting method.
 See the documentation for the variable `nnmail-split-fancy' for details."
+  (or nnmail-split-fancy-syntax-table
+      (let ((table (copy-syntax-table (syntax-table (current-buffer)))))
+       ;; support the %-hack
+       (modify-syntax-entry ?\% "." table)
+       (setq nnmail-split-fancy-syntax-table table)
+       nnmail-split-fancy-syntax-table))
   (with-syntax-table nnmail-split-fancy-syntax-table
     (nnmail-split-it nnmail-split-fancy)))

This is kludge and the first thing to check is about the XEmacs versions affected by this problem.

Best regards,

Fabrice

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

[Reiner Steib]

On Sun, Mar 05 2006, Fabrice Popineau wrote:

> * Reiner Steib <reinersteib+gmane@imap.cc> writes:
>     Reiner>  Or we could add a forth element specifying the
>     Reiner>  partial-words behavior in the split rule:
>
>     Reiner>  ("subject" ".*\\[ce\\].*" foo.ce t)
>
> I would like it, especially if the 4th element is optional.

Sure, else it won't be backwards compatible.

> Incidentally, playing with this stuff, I came with another problem. I
> don't know if it is me or me and my configuration (native win32 xemacs
> 21.5b21) but there might be problems with
> nnmail-split-fancy-syntax-table.

There are some bugs in the XEmacs 21.5 WRT syntax tables,IIRC.  See
the following in dgnushack.el:

;; Work around for an incompatibility (XEmacs 21.4 vs. 21.5), see the
;; following threads:
;;
;; http://thread.gmane.org/gmane.emacs.gnus.general/56414
;; Subject: attachment problems found but not fixed
;;
;; http://thread.gmane.org/gmane.emacs.gnus.general/56459
;; Subject: Splitting mail -- XEmacs 21.4 vs 21.5
;;
;; http://thread.gmane.org/gmane.emacs.xemacs.beta/20519
;; Subject: XEmacs 21.5 and Gnus fancy splitting.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

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

[Katsumi Yamaoka]

>>>>> In <hd6c1v90.fsf@esemetz.metz.supelec.fr>
>>>>>	Fabrice Popineau wrote:

>     Reiner>  I'd rather not put such a special treatment into the code
>     Reiner>  _if_ we can avoid it.

> I agree: the list of special cases might become too long.

I agree too.

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

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

> I would like it, especially if the 4th element is optional.

>>>>> In <v9k6b8blyd.fsf@marauder.physik.uni-ulm.de>
>>>>>	Reiner Steib wrote:

> Sure, else it won't be backwards compatible.

That's a bright idea.  It will help people who have no choice
but to set `nnmail-split-fancy-match-partial-words' to t for all
split rules even though it is required for only a few special
cases.  Well, I'll do it in the near future if nobody stands.

> There are some bugs in the XEmacs 21.5 WRT syntax tables,IIRC.  See
> the following in dgnushack.el:

[...]

Though I don't know why the bug is being left for a long time,
it might be helpful to have a copy of the dgnushack.el's code
which checks and redefines the `with-syntax-table' macro in your
init file.

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

[Fabrice Popineau]

* Katsumi Yamaoka <yamaoka@jpl.org> writes:

    > Though I don't know why the bug is being left for a long time, it
    > might be helpful to have a copy of the dgnushack.el's code which
    > checks and redefines the `with-syntax-table' macro in your init
    > file.

Ok, thanks to both of you for pointing out the relevant part of the code
in dgnushack.el.

-- 
Fabrice

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

[Katsumi Yamaoka]

>>>>> In <b4mfylw43zp.fsf@jpl.org> Katsumi Yamaoka wrote:

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

>> I would like it, especially if the 4th element is optional.

>>>>>> In <v9k6b8blyd.fsf@marauder.physik.uni-ulm.de>
>>>>>>	Reiner Steib wrote:

>> Sure, else it won't be backwards compatible.

> That's a bright idea.  It will help people who have no choice
> but to set `nnmail-split-fancy-match-partial-words' to t for all
> split rules even though it is required for only a few special
> cases.  Well, I'll do it in the near future if nobody stands.

I changed the meaning of the last element into inverting the
match-partial-words behavior.  For instance, the partial-words
matching will be made if the last element is set even if
`nnmail-split-fancy-match-partial-words' is nil.  Contrarily,
the partial-words matching will not be made if the last element
is set even if `nnmail-split-fancy-match-partial-words' is
non-nil.  The patch to No Gnus is below.

I'll install this change, add a description to the Info, and
improve some descriptions about the partial-words matching,
maybe tomorrow[1], in both the trunk and the v5-10 branch[2].

--8<---------------cut here---------------start------------->8---
--- nnmail.el~	2006-02-08 05:42:25 +0000
+++ nnmail.el	2006-03-07 09:52:16 +0000
@@ -1420,11 +1420,12 @@
 
      ;; Not in cache, compute a regexp for the field/value pair.
      (t
-      (let* ((field (nth 0 split))
-	     (value (nth 1 split))
-	     partial-front
-	     partial-rear
-	     regexp)
+      (let ((field (nth 0 split))
+	    (value (nth 1 split))
+	    (split-rest (cddr split))
+	    partial-front
+	    partial-rear
+	    regexp)
 	(if (symbolp value)
 	    (setq value (cdr (assq value nnmail-split-abbrev-alist))))
 	(if (and (>= (length value) 2)
@@ -1436,7 +1437,13 @@
 		 (string= ".*" (substring value -2)))
 	    (setq value (substring value 0 -2)
 		  partial-rear ""))
-	(when nnmail-split-fancy-match-partial-words
+	;; Invert the match-partial-words behavior if the optional
+	;; last element is specified.
+	(while (eq (car split-rest) '-)
+	  (setq split-rest (cddr split-rest)))
+	(when (if (cdr split-rest)
+		  (not nnmail-split-fancy-match-partial-words)
+		nnmail-split-fancy-match-partial-words)
 	  (setq partial-front ""
 		partial-rear ""))
 	(setq regexp (concat "^\\(\\("
--8<---------------cut here---------------end--------------->8---

[1] I need much more time for writing English text than Lisp
code ;-).
[2] I need to be able to run both the versions with the same
~/.gnus.el file.

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

[Katsumi Yamaoka]

>>>>> In <b4mu0aazihd.fsf@jpl.org> Katsumi Yamaoka wrote:

> I changed the meaning of the last element into inverting the
> match-partial-words behavior.  For instance,

[...]

> I'll install this change, add a description to the Info, and
> improve some descriptions about the partial-words matching,
> maybe tomorrow[1], in both the trunk and the v5-10 branch[2].

Done.  Please fix funny English if any.

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

[Reiner Steib]

On Wed, Mar 08 2006, Katsumi Yamaoka wrote:

>> I'll install this change, add a description to the Info, and
>> improve some descriptions about the partial-words matching,
>> maybe tomorrow[1], in both the trunk and the v5-10 branch[2].
>
> Done.  Please fix funny English if any.

The first paragraph (not modified by you) "If the split is a list, the
first element of which is a string, ..." is hard to understand, IMHO.

I also think that your text could be simplified a little and we could
use a shorter term instead of `invert-match-partial-words'
e.g. `invert-partial'.

How about the following change?

--8<---------------cut here---------------start------------->8---
--- gnus.texi	09 Mar 2006 12:33:12 +0100	6.603.2.66
+++ gnus.texi	09 Mar 2006 16:35:58 +0100	
@@ -14007,18 +14007,21 @@
 regexp match expansion will be done.  See below for examples.
 
 @c Don't fold this line.
-@item (@var{field} @var{value} [- @var{restrict} [@dots{}] ] @var{split} [@var{invert-match-partial-words}])
-If the split is a list, the first element of which is a string, then
-store the message as specified by @var{split}, if header @var{field}
-(a regexp) contains @var{value} (also a regexp).  If @var{restrict}
-(yet another regexp) matches some string after @var{field} and before
-the end of the matched @var{value}, the @var{split} is ignored.  If
-none of the @var{restrict} clauses match, @var{split} is processed.
-
-The last element @var{invert-match-partial-words} is optional.  If it is
-not omitted and the value is non-@code{nil}, the match-partial-words
-behavior controlled by the @code{nnmail-split-fancy-match-partial-words}
-variable (see below) will be inverted.  (New in Gnus 5.10.7)
+@item (@var{field} @var{value} [- @var{restrict} [@dots{}] ] @var{split} [@var{invert-partial}])
+The split can be a list containing at least three elements.  If the
+first element @var{field} (a regexp matching a header) contains
+@var{value} (also a regexp) then store the message as specified by
+@var{split}.
+
+If @var{restrict} (yet another regexp) matches some string after
+@var{field} and before the end of the matched @var{value}, the
+@var{split} is ignored.  If none of the @var{restrict} clauses match,
+@var{split} is processed.
+
+The last element @var{invert-partial} is optional.  If it is
+non-@code{nil}, the match-partial-words behavior controlled by the
+variable @code{nnmail-split-fancy-match-partial-words} (see below) is
+be inverted.  (New in Gnus 5.10.7)
 
 @item (| @var{split} @dots{})
 If the split is a list, and the first element is @code{|} (vertical
--8<---------------cut here---------------end--------------->8---

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

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

[Katsumi Yamaoka]

>>>>> In <v964mny6b2.fsf@marauder.physik.uni-ulm.de>
>>>>>	Reiner Steib wrote:

> On Wed, Mar 08 2006, Katsumi Yamaoka wrote:

>> Done.  Please fix funny English if any.

> The first paragraph (not modified by you) "If the split is a list, the
> first element of which is a string, ..." is hard to understand, IMHO.

Hm, it might be easy to understand by only ELisp programmers.

> I also think that your text could be simplified a little and we could
> use a shorter term instead of `invert-match-partial-words'
> e.g. `invert-partial'.

> How about the following change?

Thank you very much for the followup.  The structures of
sentences are considerably different between Japanese and
English[1], and I don't have confidence that everyone understands
my English, so my sentences tend to become lengthy (this is just
so, isn't it? ;-).  Anyway, I've installed your patch.

[1] For instance, the sentence "The split can be a list
containing at least three elements." you wrote is good in
English.  However, it is not very easy to translate into
Japanese.  For that case, I often translate freely in:

http://cvs.m17n.org/viewcvs/root/gnus-doc-ja/

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

[Fabrice Popineau]

* Reiner Steib <reinersteib+gmane@imap.cc> writes:

    Fabrice>  - (set-file-modes filename nnmail-default-file-modes))) +
    Fabrice>  (gnus-set-file-modes filename nnmail-default-file-modes)))
    Fabrice>  I think it should be applied anyway.  mail-source.el and
    Fabrice>  mm-decode.el also use set-file-modes.

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

The problem is that up to now, there were places where
#'gnus-set-file-modes was used and others where #'set-file-modes was
used. My point is that the same function should be used everywhere.

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

Seems ok to me. Your flag gnus-ignore-set-file-modes-errors should be t
on win32 native (don't know about cygwin).

Best,

Fabrice

set-file-modes (XEmacs on w32) (was: nnmail-split-fancy-match-partial-words)

[Reiner Steib]

On Sun, Mar 05 2006, Fabrice Popineau wrote:

> * Reiner Steib <reinersteib+gmane@imap.cc> writes:
>
>     Fabrice>  - (set-file-modes filename nnmail-default-file-modes))) +
>     Fabrice>  (gnus-set-file-modes filename nnmail-default-file-modes)))
>     Fabrice>  I think it should be applied anyway.  mail-source.el and
>     Fabrice>  mm-decode.el also use set-file-modes.
>
>     Reiner>  I didn't investigate the callers, but maybe it *should*
>     Reiner>  give an error if the modes cannot be set appropriately.
>     Reiner>  (Shouldn't the respective (X)Emacs function care for those
>     Reiner>  file system / operation system details?)
>
> The problem is that up to now, there were places where
> #'gnus-set-file-modes was used and others where #'set-file-modes was
> used. My point is that the same function should be used everywhere.

My point is that it might be better if Gnus (at least in the default
setup) should signal an error if it can't assure that the files or
directories have appropriate permissions.  Given that NTFS has the
possibility to ensure that, I think it would be a mistake to set
`gnus-ignore-set-file-modes-errors' to t by default on windows in
general.  On Windows 9x/ME and DOS -- but even there I'd think that
(X)Emacs implementation of `set-file-modes' should deal with this and
not Gnus.

>     Reiner>  *time passes* ...  After reading the discussion
>     Reiner>  <http://thread.gmane.org/gmane.emacs.gnus.general/57528>, I
>     Reiner>  think we should change `gnus-set-file-modes' as follows...
>
> Seems ok to me. Your flag gnus-ignore-set-file-modes-errors should be t
> on win32 native (don't know about cygwin).

I looked at some non-Gnus occurrences of set-file-modes in XEmacs
(21.4.17/lib/xemacs/xemacs-packages/lisp/*/*.el).  (I didn't look at
tramp and efs because those deal with remote files.)  

Only vm/vm-folder.el does something like `ignore-errors':

vm/vm-folder.el:2675:	    (vm-error-free-call 'set-file-modes index-file (vm-octal 600))

All other packages just call `set-file-modes' directly.  Could you try
if savehist-mode fails for you too?  The version from XEmacs contains:

  (set-file-modes savehist-file savehist-modes)

Maybe you could ask on xemacs-beta if it is intended that
`set-file-modes' fails in your setup or if it is a bug.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: set-file-modes (XEmacs on w32)

[Reiner Steib]

[ Not trimming the quotes because I added xemacs-beta.
  See http://thread.gmane.org/gmane.emacs.gnus.general/62158
  or  http://thread.gmane.org/gmane.emacs.gnus.general/62140
  for more context. ]

On Mon, Mar 06 2006, Reiner Steib wrote:

> On Sun, Mar 05 2006, Fabrice Popineau wrote:
>> * Reiner Steib <reinersteib+gmane@imap.cc> writes:
>>
>>     Fabrice>  - (set-file-modes filename nnmail-default-file-modes))) +
>>     Fabrice>  (gnus-set-file-modes filename nnmail-default-file-modes)))
>>     Fabrice>  I think it should be applied anyway.  mail-source.el and
>>     Fabrice>  mm-decode.el also use set-file-modes.
>>
>>     Reiner>  I didn't investigate the callers, but maybe it *should*
>>     Reiner>  give an error if the modes cannot be set appropriately.
>>     Reiner>  (Shouldn't the respective (X)Emacs function care for those
>>     Reiner>  file system / operation system details?)
>>
>> The problem is that up to now, there were places where
>> #'gnus-set-file-modes was used and others where #'set-file-modes was
>> used. My point is that the same function should be used everywhere.
>
> My point is that it might be better if Gnus (at least in the default
> setup) should signal an error if it can't assure that the files or
> directories have appropriate permissions.  Given that NTFS has the
> possibility to ensure that, I think it would be a mistake to set
> `gnus-ignore-set-file-modes-errors' to t by default on windows in
> general.  On Windows 9x/ME and DOS -- but even there I'd think that
> (X)Emacs implementation of `set-file-modes' should deal with this
> and not Gnus.

I tried with Emacs 22 (system-type = windows-nt) on an NTFS
filesystem and with Emacs 22 on GNU/Linux on a vfat USB disk:

  (require 'mail-source)
  (set-file-modes "/path/to/file" mail-source-default-file-modes)

No error.  Same with XEmacs 21.5.21 (+CVS-20050720) on GNU/Linux with
a file on the same vfat USB disk.

>>     Reiner>  *time passes* ...  After reading the discussion
>>     Reiner>  <http://thread.gmane.org/gmane.emacs.gnus.general/57528>, I
>>     Reiner>  think we should change `gnus-set-file-modes' as follows...
>>
>> Seems ok to me. Your flag gnus-ignore-set-file-modes-errors should be t
>> on win32 native (don't know about cygwin).
>
> I looked at some non-Gnus occurrences of set-file-modes in XEmacs
> (21.4.17/lib/xemacs/xemacs-packages/lisp/*/*.el).  (I didn't look at
> tramp and efs because those deal with remote files.)  
>
> Only vm/vm-folder.el does something like `ignore-errors':
>
> vm/vm-folder.el:2675:	    (vm-error-free-call 'set-file-modes index-file (vm-octal 600))
>
> All other packages just call `set-file-modes' directly.  Could you try
> if savehist-mode fails for you too?  The version from XEmacs contains:
>
>   (set-file-modes savehist-file savehist-modes)
>
> Maybe you could ask on xemacs-beta if it is intended that
> `set-file-modes' fails in your setup or if it is a bug.

Is is intended that `set-file-modes' throws an error in XEmacs in
Fabrice's setup?

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/