Hallo, Carsten Kunze <carsten.ku...@arcor.de> wrote: |Steffen Nurpmeso <sdao...@yandex.com> wrote: |> For S-roff i can say that yes, i'm open and want such an |> extension, but i will not tear up the parsers that yet exist in |> order to do so. |> I'm not yet sure but i think introducing the $ extension trigger |> seems to be a way to get this going, introducing some "outer |> state" which can be recalled once the existing parser(s) are done. |> |> Maybe $ should be turned into a two-letter mode first, however, |> say $( to mean "grouping", $r "regular expression", $c the already |> implemented string-case thing. That would be even better (though |> even uglier). | |The problem that I see is that the ".if statement" does work \ |according the specification but not as expected for those \ |who do not read the documentation carefully. So I do not \
I think that ship sailed decades ago regarding the existing constructs. Doug McIlroy wrote not too long ago "troff lives" and that's how it should be. |want do introduce a new syntax for that, just include "!" \ |and string compare inside expressions. Yes, the current syntax \ |and precedence is strange, but once you are used to it it's \ |not an issue anymore. But the missing "!" and string compare \ |inside expressions leads to problems which are not just comfort issues. Ok, but i don't think that such a change will happen for S-roff, at least not in the forseeable future, because i'd have to completely rewrite the logic, and _that_ i wouldn't do _unless_ i'd have a _complete_ set of tests which i could run to test for behaviour changes. Right now groff will not parse such parenthesized expressions via top-level .if expression checking, but pass them down to a standalone number-specific parser which seems to have a distinctive greediness... On the other hand, introducing a new top-level construct, as above, is per definition backward compatible and seems to be possible without too much messing. Can there be || and &&, i haven't looked yet (especially the former may be a problem), and not at last & and : are a choice as good as all others... In the end such new functionality wasn't really on my list for quite some time, so in fact i'm a bit overchallenged... But i would prefer if the roff's could stay in sync somewhat. Noone wins if this diverges even more. --steffen
