Re: [Groff] surprise, surprise

[Werner LEMBERG]

> > The Plan 9 source (which is essentially Bell Labs troff)
> 
> Don't I wish I had a copy !!!

It's freely available -- I've lost the pointer; Ralph, can you help?

> However, it is then not clear why \d, \h, \k, \r, \u, \v are not
> transparent, nor why "\c.test" and "\p.test" hide ".test"
> altogether.

In GNU troff, \d, \h, \r, \u, and \v produce motion nodes; \k is
handled as a special mark input token.

Everything after \c is ignored (and a transparent dummy node is
inserted).

\p produces a special spread token.

> So I propose FIRST that, for the purposes of groff, we debate on
> what "UNIX troff" really means. I don't think I have an objection to
> Plan 9 troff, even though from my point of view it's still a pig in
> a poke (Don't I wish I had a copy !!!). If we had access to the 1992
> ditroff code (which seems to be what inspired JC -- see "man
> groff-out"), then I think we could settle for that. I'm not sure
> what relationship DWB bears with that. But I think we need to
> designate something _definite_ and _verifiable_ for "UNIX troff".
> As things stand, Plan 9 troff has both attributes (and, as Ralph has
> just demonstrated, has the advantage that we can consult the source
> code whenever we wonder about "bug" vs "feature").

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

> SECOND, I propose that the detailed behaviour of groff (in
> compatibility and in "normal" mode) be verified against the
> behaviour of our designated "UNIX troff". Where there are essential
> differences, we decide whether these are bugs or features and, for
> the latter, we discuss whether to keep them.

I agree.  As already mentioned, all intentional differences should go
to the doc (or into the compatibility mode).


    Werner