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 <carsten.ku...@arcor.de> wrote (Sat, 15 Nov 2014 15:03:18 +0100 (CET)): > Steffen Nurpmeso <sdao...@yandex.com> 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 >
