unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* RMAIL against Texinfo
@ 2004-02-01 17:16 Eli Zaretskii
  2004-02-01 21:51 ` Kai Grossjohann
  0 siblings, 1 reply; 7+ messages in thread
From: Eli Zaretskii @ 2004-02-01 17:16 UTC (permalink / raw)
  Cc: Karl Berry

Recently, I became annoyed by the fact that when I reply to a message
sent via texinfo-pretest or texinfo-help mailing lists, the list
address is somehow removed from the list of addressees to whom my
reply is sent.  After some debugging, it turned out that the default
value of rmail-dont-reply-to-names was this:

    "info-\\|eliz@elta\\.co\\.il>\\|eliz\\>"

And that "info-" thingie would remove texinfo-* lists from my replies!

That seems like a simple bug to me: the intent was to remove the
"info-*" mailing lists, which are essentially read-only (you are sent
information, but are not supposed to reply), so the regexp should
have been anchored at the beginning of a word, like this:

    "\\<info-\\|\\<eliz@elta\\.co\\.il\\>\\|\\<eliz\\>"

(I think my username and email addresses should get the same anchors,
to avoid filtering out someone whose username happens to be "noteliz",
for example.)

However, given that the code, both in rmail.el and in mail-utils.el,
which did this is VERY old, I'd like to ask if someone sees any bad
side effects from the changes I suggest below.

TIA

Index: lisp/mail/rmail.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/mail/rmail.el,v
retrieving revision 1.378
diff -u -r1.378 rmail.el
--- lisp/mail/rmail.el	30 Dec 2003 11:42:37 -0000	1.378
+++ lisp/mail/rmail.el	1 Feb 2004 17:18:49 -0000
@@ -139,9 +139,9 @@
   :group 'rmail-reply)
 
 ;;;###autoload
-(defvar rmail-default-dont-reply-to-names "info-" "\
-A regular expression specifying part of the value of the default value of
-the variable `rmail-dont-reply-to-names', for when the user does not set
+(defvar rmail-default-dont-reply-to-names "\\<info-" "\
+A regular expression specifying part of the default value of the
+variable `rmail-dont-reply-to-names', for when the user does not set
 `rmail-dont-reply-to-names' explicitly.  (The other part of the default
 value is the user's email address and name.)
 It is useful to set this variable in the site customization file.")


Index: lisp/mail/mail-utils.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/mail/mail-utils.el,v
retrieving revision 1.54
diff -u -r1.54 mail-utils.el
--- lisp/mail/mail-utils.el	1 Sep 2003 15:45:29 -0000	1.54
+++ lisp/mail/mail-utils.el	1 Feb 2004 17:19:39 -0000
@@ -216,9 +216,11 @@
                       "")
                     (if (and user-mail-address
                              (not (equal user-mail-address user-login-name)))
-                        (concat (regexp-quote user-mail-address) "\\|")
+                        (concat "\\<"
+				(regexp-quote user-mail-address)
+				"\\>\\|")
                       "")
-                    (concat (regexp-quote user-login-name) "\\>"))))
+                    (concat "\\<" (regexp-quote user-login-name) "\\>"))))
   ;; Split up DESTINATIONS and match each element separately.
   (let ((start-pos 0) (cur-pos 0)
 	(case-fold-search t))

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: RMAIL against Texinfo
  2004-02-01 17:16 RMAIL against Texinfo Eli Zaretskii
@ 2004-02-01 21:51 ` Kai Grossjohann
  2004-02-02  5:59   ` Eli Zaretskii
  0 siblings, 1 reply; 7+ messages in thread
From: Kai Grossjohann @ 2004-02-01 21:51 UTC (permalink / raw)


"Eli Zaretskii" <eliz@elta.co.il> writes:

> That seems like a simple bug to me: the intent was to remove the
> "info-*" mailing lists, which are essentially read-only (you are sent
> information, but are not supposed to reply), so the regexp should
> have been anchored at the beginning of a word, like this:
>
>     "\\<info-\\|\\<eliz@elta\\.co\\.il\\>\\|\\<eliz\\>"
>
> (I think my username and email addresses should get the same anchors,
> to avoid filtering out someone whose username happens to be "noteliz",
> for example.)

This will still remove frumple-info and tex-info from the list of
addresses.

Also, there is experience with nnmail-fancy-split in Gnus, which
automatically surrounds regexes with \\< and \\>.  Users are supposed
to say ".*foo.*" if they want to undo the effect of \\<...\\>.  But
after some years it turned out that this didn't always work, and now
there is additional code in the function supporting nnmail-split-fancy
which checks for the regex starting with ".*"...  I forgot what
exactly was the problem, though.

I'm afraid that with a similar change for rmail-dont-reply-to-names,
you might fall into similar traps.  And it doesn't even cover all
cases.

A "real" solution might have to parse email addresses such that the
rules can be formulated in an unambiguous way.

Maybe it's useful to also talk with the Gnus folks, since the same
problem happens there (though in a different context).

Kai

PS: nnmail-fancy-split allows you to express which incoming emails
    should go into which group (or mail file, or folder, or ... well,
    I hope you understand what I mean).  So it does something very
    different, but it also matches regexes against email addresses.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: RMAIL against Texinfo
  2004-02-01 21:51 ` Kai Grossjohann
@ 2004-02-02  5:59   ` Eli Zaretskii
  2004-02-02  7:33     ` Kai Grossjohann
  0 siblings, 1 reply; 7+ messages in thread
From: Eli Zaretskii @ 2004-02-02  5:59 UTC (permalink / raw)
  Cc: emacs-devel

> From: Kai Grossjohann <kai@emptydomain.de>
> Date: Sun, 01 Feb 2004 22:51:31 +0100
> 
> This will still remove frumple-info and tex-info from the list of
> addresses.

So you are saying that using \` instead of \< would be better?  (I
used \< because I thought about addresses like
<info-gnu-emacs@gnu.org>, with the brackets intact.)

> Also, there is experience with nnmail-fancy-split in Gnus, which
> automatically surrounds regexes with \\< and \\>.  Users are supposed
> to say ".*foo.*" if they want to undo the effect of \\<...\\>.  But
> after some years it turned out that this didn't always work, and now
> there is additional code in the function supporting nnmail-split-fancy
> which checks for the regex starting with ".*"...  I forgot what
> exactly was the problem, though.

Well, do you see any reason that this would be relevant to the case
in point?  mail-utils.el doesn't surround regular expressions with \<
and \>, it only does that with usernames, which aren't regexps.

> I'm afraid that with a similar change for rmail-dont-reply-to-names,
> you might fall into similar traps.

Like what?

> And it doesn't even cover all cases.

Sure, but it does make the current situation better, doesn't it?

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: RMAIL against Texinfo
  2004-02-02  5:59   ` Eli Zaretskii
@ 2004-02-02  7:33     ` Kai Grossjohann
  2004-02-02 19:04       ` Eli Zaretskii
  0 siblings, 1 reply; 7+ messages in thread
From: Kai Grossjohann @ 2004-02-02  7:33 UTC (permalink / raw)


Eli Zaretskii <eliz@elta.co.il> writes:

>> From: Kai Grossjohann <kai@emptydomain.de>
>> Date: Sun, 01 Feb 2004 22:51:31 +0100
>> 
>> This will still remove frumple-info and tex-info from the list of
>> addresses.
>
> So you are saying that using \` instead of \< would be better?  (I
> used \< because I thought about addresses like
> <info-gnu-emacs@gnu.org>, with the brackets intact.)

I see.

Now I've looked in rmail-dont-reply-to and I see that I had wildly
guessed at what it might do, but I guessed completely wrong.

Lesson: always look at the source code first.

It seems that rmail-dont-reply-to-names is already anchored to the
beginning of an email address by the existing code?  Or am I
misreading?

>> Also, there is experience with nnmail-fancy-split in Gnus, which
>> automatically surrounds regexes with \\< and \\>.  Users are supposed
>> to say ".*foo.*" if they want to undo the effect of \\<...\\>.  But
>> after some years it turned out that this didn't always work, and now
>> there is additional code in the function supporting nnmail-split-fancy
>> which checks for the regex starting with ".*"...  I forgot what
>> exactly was the problem, though.
>
> Well, do you see any reason that this would be relevant to the case
> in point?  mail-utils.el doesn't surround regular expressions with \<
> and \>, it only does that with usernames, which aren't regexps.

Didn't you suggest to automagically add \\<...\\> to the regexp
constructed from rmail-dont-reply-to-names?  And
rmail-dont-reply-to-names is documented to be a regexp.

>> I'm afraid that with a similar change for rmail-dont-reply-to-names,
>> you might fall into similar traps.
>
> Like what?

After some gmaning, ISTR that there was a problem when the regex
started or ended with a non-word character.  For instance, if you
wanted to exclude the user name foo_, then auto-appending \\> to the
regex would do no good, as "foo_\\>" can never match.

It is, of course unusual for a user name to start or end with a
non-word character.  But in the case of fancy splitting in Gnus,
people would often use regexes like "foo@".

Hm.  I think that there was also a boundary case where not even adding
".*" would work.  I can't give a realistic example, but if the user
name foo_ was naked and the last one, then the string to be matched
against would end like "...foo_".  And the regex "foo_.*\\>" does not
match this string.

That's why fancy splitting in Gnus has code to detect whether the
regex entered by the user starts/ends with .*, and if so, the
corresponding \\</\\> is omitted.

Please take the above with a grain of salt; I'm giving you what I can
remember but I don't remember exactly.  As I said in my previous post,
it would be good to ask the Gnus folks for any gotchas.  (If I knew
all the gotchas already, I didn't have to suggest asking the Gnus
folks...)

>> And it doesn't even cover all cases.
>
> Sure, but it does make the current situation better, doesn't it?

It still means that there is more magic going on, and more magic is
not necessarily good.

Kai

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: RMAIL against Texinfo
  2004-02-02  7:33     ` Kai Grossjohann
@ 2004-02-02 19:04       ` Eli Zaretskii
  2004-02-03  8:34         ` Kai Grossjohann
  0 siblings, 1 reply; 7+ messages in thread
From: Eli Zaretskii @ 2004-02-02 19:04 UTC (permalink / raw)
  Cc: emacs-devel

> From: Kai Grossjohann <kai@emptydomain.de>
> Date: Mon, 02 Feb 2004 08:33:54 +0100
> 
> It seems that rmail-dont-reply-to-names is already anchored to the
> beginning of an email address by the existing code?

I think mail-strip-quoted-names removes <> and any other junk, so it
sounds like prepending \` to "info-" would be better than \<.  Do you
agree?

> >> Also, there is experience with nnmail-fancy-split in Gnus, which
> >> automatically surrounds regexes with \\< and \\>.  Users are supposed
> >> to say ".*foo.*" if they want to undo the effect of \\<...\\>.  But
> >> after some years it turned out that this didn't always work, and now
> >> there is additional code in the function supporting nnmail-split-fancy
> >> which checks for the regex starting with ".*"...  I forgot what
> >> exactly was the problem, though.
> >
> > Well, do you see any reason that this would be relevant to the case
> > in point?  mail-utils.el doesn't surround regular expressions with \<
> > and \>, it only does that with usernames, which aren't regexps.
> 
> Didn't you suggest to automagically add \\<...\\> to the regexp
> constructed from rmail-dont-reply-to-names?

Not to rmail-dont-reply-to-names, ti the user's login name and email
address.  These two are literal strings, not regular expressions.

As to rmail-dont-reply-to-names, I don't think we should surround them
with anything; it's the user's job to do so when she customizes this
option.

Thanks for the other comments, I will try to accomodate them.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: RMAIL against Texinfo
  2004-02-02 19:04       ` Eli Zaretskii
@ 2004-02-03  8:34         ` Kai Grossjohann
  2004-02-03 10:13           ` Eli Zaretskii
  0 siblings, 1 reply; 7+ messages in thread
From: Kai Grossjohann @ 2004-02-03  8:34 UTC (permalink / raw)


"Eli Zaretskii" <eliz@elta.co.il> writes:

>> From: Kai Grossjohann <kai@emptydomain.de>
>> Date: Mon, 02 Feb 2004 08:33:54 +0100
>> 
>> It seems that rmail-dont-reply-to-names is already anchored to the
>> beginning of an email address by the existing code?
>
> I think mail-strip-quoted-names removes <> and any other junk, so it
> sounds like prepending \` to "info-" would be better than \<.  Do you
> agree?

In that case, sure.  (I'm somewhat confused about what does the string
look like that's passed to rmail-dont-reply-to-names.)

>> >> Also, there is experience with nnmail-fancy-split in Gnus, which
>> >> automatically surrounds regexes with \\< and \\>.  Users are supposed
>> >> to say ".*foo.*" if they want to undo the effect of \\<...\\>.  But
>> >> after some years it turned out that this didn't always work, and now
>> >> there is additional code in the function supporting nnmail-split-fancy
>> >> which checks for the regex starting with ".*"...  I forgot what
>> >> exactly was the problem, though.
>> >
>> > Well, do you see any reason that this would be relevant to the case
>> > in point?  mail-utils.el doesn't surround regular expressions with \<
>> > and \>, it only does that with usernames, which aren't regexps.
>> 
>> Didn't you suggest to automagically add \\<...\\> to the regexp
>> constructed from rmail-dont-reply-to-names?
>
> Not to rmail-dont-reply-to-names, ti the user's login name and email
> address.  These two are literal strings, not regular expressions.

Oh, you're suggesting to change the default value of
rmail-dont-reply-to-names!  Okay.  That's something else entirely.
Sorry that I didn't get this before.  Good idea.

(The beginning of rmail-dont-reply-to looks strange: in the code (if
(null X) (if X foo bar) baz) it seems like foo will never be executed.
X is rmail-dont-reply-to-names.)

> As to rmail-dont-reply-to-names, I don't think we should surround them
> with anything; it's the user's job to do so when she customizes this
> option.

Right.  That's what I was trying to say.

Kai

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: RMAIL against Texinfo
  2004-02-03  8:34         ` Kai Grossjohann
@ 2004-02-03 10:13           ` Eli Zaretskii
  0 siblings, 0 replies; 7+ messages in thread
From: Eli Zaretskii @ 2004-02-03 10:13 UTC (permalink / raw)
  Cc: emacs-devel

> From: Kai Grossjohann <kai@emptydomain.de>
> Date: Tue, 03 Feb 2004 09:34:11 +0100
> >
> > I think mail-strip-quoted-names removes <> and any other junk, so it
> > sounds like prepending \` to "info-" would be better than \<.  Do you
> > agree?
> 
> In that case, sure.  (I'm somewhat confused about what does the string
> look like that's passed to rmail-dont-reply-to-names.)

The function rmail-dont-reply-to gets the string that lists the full
addresses which are candidates for being replied to.  It then extracts
each individual address one by one, runs it through
mail-strip-quoted-names (which converts "Foo Bar <foo@bar.baz.biz>"
into just "foo@bar.baz.biz"), and if the result matches
rmail-dont-reply-to-names, it removes the matching address from the
list of destinations.

> Oh, you're suggesting to change the default value of
> rmail-dont-reply-to-names!

Yes.

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2004-02-03 10:13 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-02-01 17:16 RMAIL against Texinfo Eli Zaretskii
2004-02-01 21:51 ` Kai Grossjohann
2004-02-02  5:59   ` Eli Zaretskii
2004-02-02  7:33     ` Kai Grossjohann
2004-02-02 19:04       ` Eli Zaretskii
2004-02-03  8:34         ` Kai Grossjohann
2004-02-03 10:13           ` Eli Zaretskii

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).