Re: Procmail 4.0 WishList

Michael J Wise wrote:

> Um... So you're telling me that a program that knows what to do with
> this:
[specific sample of proposed syntax]

> Could not also understand (and do the right thing with) this:
[two samples of a single current syntax, which interestingly was
 a recipe with no conditions]

> If so, why?
Don't put words into my mouth.  I never said that every last bit of 
current procmailrc syntax would break and that you couldn't come up with 
a single exception.
Yes, you found one that could survive.  You want another?  Variable 
assignments would survive in their current form as well, but there are 
many other forms valid now that would change in meaning under those 
proposals.
For starters consider these four that I thought of immediately upon 
reading the earlier posts:
Using unescaped braces to specify the number or range of repetitions 
conflicts with existing rcfiles where a brace in a regexp means a 
literal brace character.
Currently rcfiles may have blank lines anywhere that look good to the 
writer, and in recent versions blank lines may even interrupt recipes. 
The proposal is that if the line after a blank line is neither a 
variable assignment nor another blank line, it is the first condition of 
a new recipe.
The suggested use of a colon to start a condition, even if it had some 
way to recognize current-syntax flag lines, would break old pre-asterisk 
rcfiles where a regexp condition begins with a literal colon to match a 
colon.  True, there is no such problem with a plus sign.  Whether there 
is with greater-than or less-than signs at the beginnings of action 
lines, I can't say, because I don't understand how this new mail thrower 
will know which line is the action and not another condition.  By 
reading ahead to see if the next line is blank?  I remember how much 
Stephen tried to avoid any situation where procmail had to read an 
additional line in order to know what to do with the current line, so 
that there would never be any backing up in the rcfile.  Perhaps backing 
up doesn't bother the redesign team.
The proposal also includes multiple actions from a recipe without the 
need for :0A before each additional action.  So if a single word appears 
below an action line, currently that unsets the variable by that name; 
under the proposal, it would be an additional action, saving a copy of 
the message to a folder by that name.
All four of those would change the meaning of syntax that is legal now.

Now, here's a proposal of theirs that would not break anything in 
existing rcfiles, because it uses a currently invalid syntax: hanging 
multiple pipe or filter actions off a recipe without :0A to introduce 
each of the additional ones.  Additional actions other than pipes or 
filters -- such as forwards to other addresses or saves to folders -- 
might be a syntax problem, but pipes and filters wouldn't.
So you found one sample of current syntax that could survive.  There are 
many more.  But there are also many that would be broken.
The redesigners either care about backward compatibility or they don't. 
 If they do, they can't introduce forms that break it.  If they don't 
care about it and they break it some of the time, they can't wave the 
backward compatibility flag in the places where they didn't break it.
If they want to support ":0" because they like it, or because you like 
it and they're beholden to you, fine.  But they're also making many 
changes that are not backward compatible, so on the occasions when one 
is, they cannot claim that backward compatibility was their intention.

____________________________________________________________
procmail mailing list   Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail