Re: `nnmail-split-fancy' regexp

[Alexandre Oliva <oliva@dcc.unicamp.br>]

[-- Attachment #1: Type: text/plain, Size: 2528 bytes --]

On Jun 24, 1999, Per Abrahamsen <abraham@dina.kvl.dk> wrote:

> "Petersen Jens-Ulrik (NRC/Tokyo)" <jens-ulrik.petersen@nokia.com> writes:
>> I found the restriction that string VALUE regexp's should match to
>> whole words too restrictive...

> There are zillions of nnmail-split-fancy rules written using that
> assumption, and many of them represent a huge work effort.  Mine has
> approximately 300 rules.  

> If you want the rules to be interpreted differently, invent a new
> variable and a new split method for it.

How about using a magic meaningless prefix to select non-full-word
matches, say, `[partial]'.  I doubt anyone starts their VALUE splits
with `[partial]', particularly because of the duplicate `a', which
wouldn't be totally useless in terms of regular expressions.  I've
just implemented it; patch attached.

While I was at it, I took the time to introduce a new feature that I
had requested for some weeks ago.  As a memory refresher, the problem
was that I subscribed to the "libtool" and "bug-libtool" mailing
lists, and there was no way to avoid that messages posted only to
"bug-libtool" were cross-posted to "libtool" without preventing
cross-posting when the message was *really* posted to both lists.  The 
syntax I've come up with is:

(FIELD VALUE [- RESTRICT [- RESTRICT [...]]] SPLIT)

So that now I can write:

(| (& (any "libtool@gnu\\.org" - "bug-libtool" "libtool")
      (any "bug-libtool@gnu\\.org" "bug-libtool")
      ;; ...
      )
   "misc")

The construction above is not equivalent to:

(| (& (any "libtool@gnu\\.org" (| (any "bug-libtool@gnu\\.org" nil)
                                  "libtool"))
      (any "bug-libtool@gnu\\.org" "bug-libtool") ;; ...

because the latter would not cross-post in case a message is posted to
both mailing lists, whereas the former will.  A RESTRICT clause will
only be considered if there is a match that starts after the end of
the FIELD match and ends after the beginning of the VALUE match.


And since I was rewriting that code anyway, I took the time to fix the
searching mechanism so that it looks for multiple matches of FIELD
VALUE, so that SPLITs that involve \N substitutions are properly
handled, causing cross-posting without introducing duplicates.


-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
{oliva,Alexandre.Oliva}@dcc.unicamp.br  aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
*** E-mail about software projects will be forwarded to mailing lists

[-- Attachment #2: partial&restrict.patch --]
[-- Type: application/x-patch, Size: 10195 bytes --]