Re: [Groff] surprise, surprise

[Werner LEMBERG]

> >   . In compatible mode, stay with the current behaviour as shown
> >     above.
> 
> Presumably, that means the groff deviations from Unix troff
> behaviour still exist?

??? I don't understand your sentence.  Please explain.

> >   . In non-compatible mode, the requests \f, \H, \R, \s, and \S are
> >     now grouped as `transparent escapes'; starting a line with one of
> >     them no longer preserves the beginning-of-line flag.
> 
> What perspective was used for the terminology?  It seems to me that
> \f, etc., have been made opaque, not transparent, in that they clear
> the bol flag and therefore have a side-effect.  I'm not saying it's
> wrong to call them transparent, I'd just like to know the reasoning
> as an aide memoir.

You are right, it was a bad decision.  I'll change it to opaque. :-)

> Is it really necessary to deviate groff from troff in this way?

Is there any real use of being compatible with this undocumented
behaviour which IMHO only adds complications without benefits?

> It's an extra thing to document, and worse, an extra thing to be
> read and understood by everybody.

I would argue exactly the other way round.  As Ted explained, he
discovered this troff anomaly by trial and error -- I wonder how many
hours he spent to fully explore it.  If this problem weren't here, he
had actually *saved* time.

> More complexity in the code, etc.

Not at all.  It is much more natural in groff's code that all escapes
return a token instead of continuing a loop.

> Why not just leave well alone and fix the troff incompatibilities.

If you use -C, it tries to be as compatible as possible.

> It seems as if groff is a bit too keen to fix troff's perceived
> faults without weighing up the associated costs.

Costs?  Which costs?  groff is not the holy grail.  I much prefer a
consistent interface to an inconsistent compatibility.


    Werner