Re: Suggestion for Enhancement; B, H, ... and D

> Because it's currently legal syntax for something else;
| I'm thinking more along the lines of having recipes which don't
necessarily
| utterly BREAK older syntax, as changing the flag parsing.  In an older
| procmail, the example would simply fail to match (unless, of course, the
| user were inverting the result).  Not really a good idea, since if the
| recipe doesn't work properly, it shouldn't be there.

Sean, you're looking at it backwards.  Yes, an older binary can't handle the
new syntax; that's inevitable with an upgrade.  The problem is that a newer
binary will misinterpret the old syntax, and we can't allow that.  What if
someone has a regexp that ends with "/D" because the search pattern ends in
slash-D?

> Illustration, s'il vous plaît?
| I don't have a ready-made one, but think like \< and \> being wordbreak
| expressions - one could have something similar that expresses a flag-on
and
| flag-off.  \<D \>D type of thing (but not exactly that syntax, of course).

OK, thanks.  For example, any pattern between \D and \d is case-sensitive
and any pattern between \d and \D is case-insensitive, overriding the
presence or absence of the `D' flag?  Now, you see, that would present no
problem with reading older rcfiles, because so far there has been no reason
to escape a d, and anyone searching for backslash-D would already have
written \\D, which will still mean the same thing.

> The question is, other than B, D, and H, what current flags would make
sense
> there?
| Think outside the box - not just what _current_ flags, but what might be
| developed in the future.

Yes, I understood that part; I was just also wondering how much already is
inside the box in order to gauge how much priority such a project should
get.

| Similar to E, what about an OR clause (ignore choice of specific letter
below):
|
| * ^From:.*something
| *+ O + ^Reply-To:.*somethingelse

No, you can't put "or" onto some conditions and leave "and" implicit on
others, because then there are questions of grouping.  You have to apply OR
or AND to an entire recipe.  An ORing flag on the colon line would be nice,
but it makes no sense on individual conditions.  So you haven't found
anything yet to join D inside the box.  I'm not saying to give up looking!
There could be modifiers applicable to individual conditions that would make
no sense on the flag line, for example, for which that syntax would work.
[There already are some modifiers that apply only to individual conditions
and wouldn't make sense for a whole recipe: !, $, var ??, ?, <,  >, and w^x
for examples.]

| Within the current system
| (which works fine for my needs), one uses scoring to enable or
conditions -
| though that has issues with efficiency (stopping as soon as we have the
| necessary match for instance).

There is no efficiency problem if you use supremum weights in the right
places, or if you use the double-reverse DeMorgan trick.  I posted about
that to procmail-dev a couple of months ago, and no one had any comment.

But maybe the question here, when all is said and done, isn't yet about
opening a portal for extensibility but so far only to define a way to make
individual conditions case-sensitive or case-insensitive.


_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail