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

[Steffen Nurpmeso]

"Denis M. Wilson" <address@hidden> wrote:
 |

 |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.
 |
 |Since the evaluation is done at runtime I can't see a problem \
 |with variables,
 |although it would enable some very obfuscated code...

I don't understand this, actually.

--steffen