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

[Steffen Nurpmeso]

Hello,

Ralph Corderoy <address@hidden> wrote:
 |>>>     (Ex; expr )
 |> 
 |> This is a nice idea and indeed a possible solution to the problem.
 |> However, I think it's probably too restricted to cover all aspects
 |> people were discussing here.

 |> After reading this thread I think the best solution is to define a new
 |> request, for example `.ifx' (`if' extended).  Then it would be
 |> straightforward to define a new, flexible syntax that is not hampered
 |> by backwards compatibility.
 |
 |And .whilex?  If we've a new .ifx, which I think is a bit clunky, maybe
 |we should bear in mind having a .elif and .else too that don't need the
 |.ifx to be .iex.  (Or .elsif;  Python use elif, Perl elsif.  elsif at
 |least sounds like `else if'.)

That was my thinking also -- and i really would like to see .elif,
it is closer to .el and also used by sh(1) ;)
(No more \}\}\}\}\} on a mysterious indentation level!)

 |Plumping for (E; expr) leaves control structures as a separate thing to
 |think about.

I personally don't like neither Carsten's N idea nor (X;).
The former has the problem that a lot of letters are yet used,
including lowercase n, meaning that there is no immediate visual
indication that the expression is of an extended kind, so to say.

That is also true for the latter, but here in addition we need to
peek forward at multiple characters before it becomes clear what
to do with the expression in question.  That means we would either
need a buffer or require several character unget() which is not
standard.  (I have seen several places where groff already does
the latter by wrapping into its own subclass, though.)

I still think $s'a'b'c'd'$, $( .. )[$] would be both, possible and
interesting; it would be possible to not require the closing $ at
EOL, just like what NetBSD does with .netrc parsing.
It is visually outstanding, and $' is known to bash()/mksh()/+
users to place special meaning onto what comes next.  The
two-letter approach is extensible, and $s'a'b'c'd'e'$ is ugly, but
when there is $('a'b' || 'c'c') then there is no need to use it.

--steffen