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

On 02/16/2002, 18:13 -0600, David W. Tamkin wrote:
> [...]  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.]
OR/AND suggests grouping ; is it possible/efficient to define blocks?

:0 [flags & co] # Head inchanged
(   # sub-block begins...
    * condition1.1
    * condition1.2
)(  # this sub-block is ORed with the first one
    * condition2.1
    # ...
)   # sub-blocks chain ends here.
* condition3
action

Of course, if opening parenthesis is legal at the beginning of the action
line, some other pair must be used, as [] or <>. 

Prefixing () with * is not possible, neither <> ; are *{} or *[] legal?

> 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.
Flags BHD could follow block opening, as in

:0: # normal head
* condition1
* condition2
( D # some case sensitive condition(s)
    * condition3.1
    * condition3.2
)   # first block ends here
( B # body condition(s), case insensitive
    * condition4.1
)   # second block end
* condition5
action

Those two blocks are *not* Ored => *{} syntax is clearer?
-- 
Jacques L'helgoualc'h
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail