Re: [Groff] surprise, surprise

[Ralph Corderoy]

Hi Werner,

Here's my now regular attempt to pull together the separate threads
back into one :-)

First off, I think everyone's agreed that groff in compatibility mode
must treat escapes as either transparent or opaque in the same way as
troff.

> > Presumably, that means the groff deviations from Unix troff
> > behaviour still exist?
> 
> ??? I don't understand your sentence.  Please explain.

I mean that currently groff, even in compatibility mode, doesn't match
troff in its view of escape transparency.

> > \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.

> > Agreed, the User's Manual is just that.  It is the source which has
> > the final word on the behaviour and unless that behaviour can be
> > shown to be broken, i.e. Kernighan agrees and doesn't say `No, Joe
> > was quite insistent that it should behave like that', then I don't
> > think we've the right to re-design troff.
> 
> I disagree.  It is my good right as a developer to improve groff.
> Compare this to, say, eTeX, an `improved' version of TeX: If you
> don't set a particular flag, all extensions are disabled.  Otherwise,
> you have a bunch of functions which not only extend TeX but also fix
> some flaws in TeX's design.

OK, can we look at this from a different perspective.  When James Clark
wrote groff he *improved* on troff by removing limitations in terms of
array lengths, etc., and also added the most useful extension around,
that of long identifiers.

This unavoidably introduced compatibility problems in parsing and so
Clark introduced the -C compatibility option.  Hope I'm right so far.
Breaking compatibility was worthwhile because of the reward.  I'm sure
if the source of Bell Labs troff wasn't so structured around 16-bit
integers holding identifiers they would have already made the same
improvement.

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

How many things have had to be added under the -C option since then?
Was the reward of having any of them as great as the long identifiers?
And were they worth the costs of having them;  I'll come back to that
later.

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.  If Ted does still cover user
issues then I think his input should be considered on this.  It seems
like your mind was made up when you first discovered the `surprise'
what the solution was to be.

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.

Also, documentation...

> > 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.

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.

As you said, "While documenting GNU troff I'll try my best to collect
all the differences between the various troff versions, especially
explaining how GNU troff differs (even in compatibility mode)."

> If this problem weren't here, he had actually *saved* time.

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?

> > 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.

The consistent interface is being consistent with troff.  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.

> > 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?

Yes, being compatible means groff doesn't differ from the (now)
documented behaviour making code and documentation comprehension
easier.

> > Agreed.  I know Kernighan doesn't even have a set of compilable
> > source these days but if you like I could approach him for his
> > preference;
> 
> This is a nice idea.

OK, I'll claim this so he doesn't get lots of requests from different
people.

I also have some questions about a test suite that I'll try and write
up under a separate thread.

Cheers,


Ralph.