Re: [Groff] surprise, surprise

[Werner LEMBERG]

> > > \p doesn't hide .xx, does it?
> > 
> > In groff it does.  May I ask that someone is testing all escapes
> > which don't expand to something whether they hide .xx in Unix
> > troff?  Based on those results I could improve GNU troff's
> > compatibility mode.

> 
> That's an example of what I meant.  If no one else steps forth I'll
> try and come up with a list based on the Plan 9 code and/or AIX
> 3.2.5 observation.

Please do so.

> Did the compatibility option cover anything else apart from these
> `long identifier' parsing issues when Clark moved on?

Yes.  groff preserves the input level in delimited arguments if not
invoked with -C:

  .ds xx '
  \w'abc\*(xxdef'

     => 168
     => 72def' (compatibility mode)

> How many things have had to be added under the -C option since then?

Interestingly, all features regarding -C affect only one file,
input.cc, which reads the input and converts it to input tokens.
Other incompatibilities (as documented in troff.man or groff.texinfo)
are not affected by this switch and thus can't be turned on or off.

> Was the reward of having any of them as great as the long
> identifiers?

The input-level stuff makes the processing of data more reliable IMHO.

> Also, is this not a `user issue' in that it affects user's view of
> groff as opposed to an internal re-design?  If so, is
> http://www.gnu.org/software/groff/ up to date when it says
> 
>     User issues lead: Ted Harding address@hidden
>     Technical issues lead: Werner Lemberg address@hidden
> 
> or is the split more fuzzy than that.

Hmm, maybe Ted can be considered as the `groff hot line for user
questions'...  I do all the coding.

> As to the costs of making groff behave differently without -C.
> 
> Code complexity increases; it must do because there are additional
> lines due to checking whether -C was specified.

As mentioned in another mail, a person reading the code in the
token::next() function before my recent changes had probably problems
to understand why there was just a `break;' for some escapes and no
`return;' (as with all other escapes).

> That's just a reason for documenting it.  Have groff always behave
> like troff in this respect and just bring it out into the open so it
> isn't a surprise.

It will be documented!  But why shall I have troff's bizarre
(undocumented) feature as the default?

> But unfortunately, `fixing' groff won't make troff's behaviour go
> away so you'll have to document troff's behaviour anyway.  Why add
> to the confusion by having groff be different?

I doubt that there will be any confusion.  If a die-hard person plans
to write a document to be processed with UNIX troff, he always has to
use the -C flag in groff for right processing.  If he or she ever uses
a groff feature like long names, it won't run with UNIX troff anyway.

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

If Galileo had this point of view (i.e. consistend with the dogmas of
the Catholic church) we would still believe that the Sun revolves the
Earth :-)

> It's too late to take what you perceive to be the flaws out of
> troff.  You can enhance it, but troff is troff.  Having another
> behaviour switch on -C is what introduces an inconsistent interface:
> troff v. groff.

This dilemma exists since Clark has decided to implement support for
long names.  UNIX troff is dead.  GNU troff has a chance even today,
so I want to improve it, not being paralyzed with bizarre features.

> > Is there any real use of being compatible with this undocumented
> > behaviour which IMHO only adds complications without benefits?
> 
> Yes, being compatible means groff doesn't differ from the (now)
> documented behaviour making code and documentation comprehension
> easier.

I fear we won't agree on this point.  Maybe this is the conflict
between young and old -- I've never used UNIX troff...


    Werner