emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RMAIL against Texinfo


From: Kai Grossjohann
Subject: Re: RMAIL against Texinfo
Date: Mon, 02 Feb 2004 08:33:54 +0100
User-agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.2 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

>> From: Kai Grossjohann <address@hidden>
>> 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
> <address@hidden>, 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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]