At 03:25 PM 8/23/97 +0200, Martin Ramsch wrote:
Hello,
I don't know what plans Stephen van den Berg does have with procmail,
but maybe the following idea might get taken into consideration?
(If it's reasonable at all :-)
With the recent talk about how to connect conditions with "or", I
thought about how to add this feature more conveniently with as few
changes to current procmailrc syntax as possible so to maintain
maximum compatibility.
What I came up now is that we could consider _indentation_:
I think that's a bad idea. If nothing else, it would break
many existing .procmailrc files. Typos become incredibly
easy. And just how many spaces equals a TAB character anyway?
[snip]
e.g.
* A1
* A2-a
* A2-b1
* B1 --> (A1 or (A2-a and A2-b1)) and B1
I *had* been looking into proposing an "OR" feature, but
wanted to be sure it would be syntactically "whole" and
wouldn't break very many existing .procmailrc files.
Basically, my idea would use + for OR along with * for AND.
e.g., something like:
# A or B and C:
* A
+ B
* C
equal precedence; evaluated top to bottom. This one would
be (A or B) and C. The first condition could start with
either * or +.
Parenthesis looked a bit tricker; was debating going with
things like ( and ) on their own lines, possibly (( etc.,
and/or things like (* (+ +( *( etc.; however the
*( breaks some regexps that might be in use. The + breaks only
folder filenames that start with + (fix: use ./+).
Quite possibly the whole thing might be controlled by setting
a variable, say ORPLUS=yes, to not break anything -- but then
we'd keep getting posts from countless people who left it out.
Your suggestion about rearranging things to avoid parentheses
doesn't address issues such as 1) it's easy to mess up :),
2) it will be desirable to arrange conditions in terms of
expected frequency and cost of evaluating different conditions,
and 3) the value of $MATCH desired when \/ is used.
I didn't have a look into the Procmail source code yet, but I hope
that such an extension could be done with an acceptable effort?
I had downloaded the source to look at it for just this purpose
a couple of months ago. It looks to affect just one place
in the code, and probably isn't too hard, as long as you don't
have to look at condition X+1 to decide whether condition X
needs to be evaluated. Yours is probably harder; I think
leading white space is stripped elsewhere, but I haven't
looked for that at all I confess.
What's "acceptable effort" for no pay though, especially when
it doesn't add any functionality, just convenience?
If I had nothing else to do (or when that happens again) I'd
volunteer to do this if "blessed by Stephen," but right now
I'm too busy.
What do you think?
Regards,
Martin
Cheers,
Stan