groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Carsten Kunze
Subject: Re: [Groff] condition: OR of two string comparisons
Date: Sat, 22 Nov 2014 21:46:15 +0100 (CET)

Hi Ralph, 

> > (It was unfair to put the .ds after .if !\w and .if d ... :-)
> 
> I didn't write it;  it's real code from groff's distributed macros.  :-)

I meant that there was the condition *and* the conditional statement on the
same line which has made this example looking more complicated than the
other.

> > >     Whitespace aids grokking expressions.
> >
> > Are whitespace not already allowed in groff?
> 
> Only if the whole expression is surrounded by parenthesis.

That's ok.  So I think regarding whitespace groff already has
anything one needs.

> > > How would it `x' work for .ds rather than .nr?
> >
> > x would mean "extended numerical expression".  .ds doesn't accept
> > numerical expressions.
> 
> I'm interested in better expressions, string and numeric.  It's poor
> string expressions that got us into this via 'c'a'b'c'd'e'.

(BTW: I don't know the semantic of 'c'a'b'c'd'e' ... :-)

The result of a string compare is a boolean value which is comparable
to the result of \\nA>5.  So I see no relation of .ds and expressions,
one could put "foo"bar" inside an expression (actualy this is planned
for Heirloom).

So for Heirloom I will allow e.g.:

.nr A \\nB!=3:(!"\\*C"blah")

It is compatible since this is invalid syntax at the moment.

Groff could use something more comfortable here (whitespace,
precedence etc.) if the groff users want that.

> > The key to new users are the macro packages.  If they are comfortable
> > there can't be any arguments against the troff language.
> 
> I don't see how one follows from the other.  The macro package may be
> superbly powerful, easy and clear to use.  It doesn't mean the
> underlying language doesn't have problems.  (Fortran 77 was used to
> write a lot of good programs.)  We need new users that won't shy away
> from troff on seeing beyond some macros.

The input language is the main criticism of roff today (by users who use
LaTeX or GUI tools).  Their argument vanishes with a comfortable macro
package.  That can hide nearly anything from the complicated low level
language.  So MOM is the interface to new users, not the .if statement.

In the past I had used LaTeX nearly 20 years. I like it a lot, even I don't
know anything about TeX.  The first simple LaTeX conditional I learned
an used a few months ago ;)  LaTeX is easy to use and *is* readable.
It hides the unreadable TeX perfectly.

The output is of course important too.  I had no problems with LaTeX but
there is one with groff.  In german texts with long words hyphenation is
used often.  At first I configured 3 consecutive hyphenated lines.  Then
often the 4th line look ugly since hyphenation was forbitten here.  So I
configured 4 lines.  Then the 5th had the problem.  Now I use 6 lines.
Rarely the 7th has the problem.  But I have paragraphs where all 6 lines
are hyphenated.  This is a weak point of groff.  So one who uses LaTeX
may say he doesn't want to change to groff because of that.

Groff should get a paragraph-at-once formating algorithm *which is not
behind TeX* (I mean not a simplified one).  The computing resources
for such an algorithm may not be a problem anymore.  Or one switches
it off to save a few seconds processing time.  This is IMHO much more
important to attract new users than how the .if statemant looks like (They
should learn groff with the MOM manual and not with CSTR54 :-)

Carsten



reply via email to

[Prev in Thread] Current Thread [Next in Thread]