"Denis M. Wilson" <d...@oxytropis.plus.com> wrote: | |Steffen Nurpmeso <sdao...@yandex.com> wrote: |> Carsten Kunze <carsten.ku...@arcor.de> wrote: |>|Steffen Nurpmeso <sdao...@yandex.com> 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
