Re: [Groff] surprise, surprise

[Ralph Corderoy]

Hi Ted,

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

I'm not your fairy Godmother :-)

CD for GBP16.00.

    http://www.vitanuova.com/plan9/main.html

Plan 9 LXR.

    http://offworld.fac.cs.cmu.edu/cgi-bin/9login

(src/cmd/troff.)

> This could explain why \fB (etc), \s, \H, \S, \R are transparent, and
> certainly why anything like \- or \n[num_reg] is not transparent.
> However, it is then not clear why \d, \h, \k, \r, \u, \v are not
> transparent

At least some of those, \h, \u, ..., are implemented by getch returning
a `character' (32-bit integer) which is then used by the command/text
switch.

> nor why "\c.test" and "\p.test" hide ".test" altogether.

\c consumes the rest of the line?  \p doesn't hide .xx, does it?  It
just `spreads' the result.

> I agree with this last statement (see my previous post): I don't
> think the manual is quite so sacred a text! And certainly you can
> read it the other way once you realise there's another way to read
> it!

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 think we need to designate something _definite_ and _verifiable_
> for "UNIX troff".

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;  he
might not be able to provide the source itself though.  I think Rob
Pike was trying for a while recently to get Caldera (or is it someone
else now) to release some of the Unix source.

> I am against going for commercial variants (Solaris, XENIX, ... )
> because it is known that these were often changed in details from
> the originals (no matter how fine their documentation might be).

Agreed, I'd favour a Bell Labs Edition, or USL at worse.

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

groff's compatibility flag seems too limited AFAICS.  It's an `all or
nothing' approach.  That may be something to consider at the same time.


Ralph.