Re: [Groff] condition: OR of two string comparisons

[Denis M. Wilson]

Here is another idea. Use the existing (;) notation eg as follows

    (Ex; expr )

Where x is the existing unit indicator, E indicates an extended
expression and expr differs from current expressions in having
(a) operator priority;
(b) new string, matching and regular expression operators (Posix conformant).

Details to be defined, but this would not break existing groff scripts.
Note: regexp is computationally more demanding.

On Thu, 13 Nov 2014 20:09:32 +0100
Steffen Nurpmeso <address@hidden> wrote:

> Carsten Kunze <address@hidden> wrote:
>  |Steffen Nurpmeso <address@hidden> wrote:
>  |> Well.  Why not restricting this by saying that a new conditional
>  |> mode (don't nail me down onto it: .if @'LHS'RHS') is introduced
>  |> where RHS (or LHS) is _not_ subject to token processing, but
>  |> _only_ to regular expression matching, e.g.
>  |> 
>  |>   .ds idea La terre est femme
>  |>   .i[ef]re '\\*[idea]'^.*?terre.*' .tm cryptic cryptic tralla
> lalala |
>  |Exactly.  Or the whole pattern could be a variable (containing \
>  |the pattern).  But a mix of literal pattern and variables \
>  |does not make sense.
> 
> Nah, doesn't sound sensi__ful what you say. : )
> Anyway i for one will not come to this for a long long time given
> the backlog of work i have, and my superficial knowledge of the
> internals of groff.  I tend to believe Tadziu and Ralph.  Even
> with a special expression prefix we would have find a way to
> expand the left hand side (\*[idea]) to a plain string in order to
> match that, _or_ create a regular expression aware node class in
> order to use the normal matching mechanism that exists today, in
> which case the RHS could also be variable -- but i wonder how
> could that be done.  So as of today i think you're right, but
> a node_list_to_string() and the above is the only thing i would
> dare to implement in the near future; but as i said, i think
> you are right.
> 
> --steffen
> 

Since the evaluation is done at runtime I can't see a problem with variables,
although it would enable some very obfuscated code...

Denis

--