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

At 14:40 2002-02-16 -0600, David W. Tamkin wrote:
> Sean had to ask,
> | * ^Subject:.*sometext/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.
> | Alternately, have a "sensitivity on" "sensitivty off" marker pair (and if
> | we're going to introduce that, it'd make sense to ensure that the markers
> | inherently support multiple flagging types, so that it can be easily
> | extended in the future)?
>
> 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).
[snip]
> ** might look like a typo there but *+ would not.  *? is already in use.
>
> Another possibility would be two asterisks or two plus signs after the
> single-condition flags, on the model of "var ??" now.  It could be
>
>  * BDjk ** ^Subject:.*sometext
> or
>  * BDjk ++ ^Subject:.*sometext
>
> 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.
>   Digits, A, a, E, and e apply to all conditions if any,
Similar to E, what about an OR clause (ignore choice of specific letter below):

* ^From:.*something
*+ O + ^Reply-To:.*somethingelse

Certainly, these can be combined into one line with current expressions - 
but what if you're running an external program?  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).

---
 Sean B. Straw / Professional Software Engineering

 Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
 Please DO NOT carbon me on list replies.  I'll get my copy from the list.

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