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

[hohe72]

I cannot see a benefit in anything other/new than the prefix indicator
that already exists. The concept is scalable and should be used. In
input.cpp the ifelse construct used for prefix chars, that should be
converted to a switch (I already did it), is equally to the switch used
for requests. To introduce bashism into groff is a wedding of two
complicated syntaxes. Programming is not a competition.

On the other side. One should first talk about the comparison. Will it
become part of the expression evaluation (usually numbers only yet),
will it use the available string comparing (maybe altered) or should a
completely new regex/raw c-string comparing happen (missing
groff-variables)?

The current string comparison isn't easy be transformed to variable
arguments behavior. It's fixed at two and therefore don't need to care
for an expression terminator.

BTW, the typology "extended" has void meaning!

Holger


Carsten Kunze <address@hidden> wrote (Sat, 15 Nov 2014 15:03:18
+0100 (CET)):
> Steffen Nurpmeso <address@hidden> wrote:
> 
> > 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.
> 
> What precise problems to you see?
> 
> It is exactly my intention that there is no visual indication for
> that.
> 
> Many may have writen in the past things like
> 
> .if \\nA=1&(\\nB!=2) ...
> .if \\nA=1&(!\\nB=2) ...
> .if \\n(.$>1&"\\$1"-L" ...
> 
> and had been surprised that it doesn'd work.  This will be "fixed"
> then, that's it.  Of course--if that would not be compatible anymore
> this way is not feasible.  You and Ralph may be right regarding that
> but at the moment I can't imagine any problem.
> 
> Carsten
>