Re: [Groff] surprise, surprise

[Ted Harding]

Hi Ralph,
Many thanks for this contribution.

On 28-Aug-01 Ralph Corderoy wrote:
> Having looked into it I'm convinced that allowing . or ' commands to
> be preceded by \ commands is intended and documented.
> 
> The Plan 9 source (which is essentially Bell Labs troff)

Don't I wish I had a copy !!!

> has this structure.
> 
>     loop:
>         ch = get_character()
>         if ch is . or '
>             process_control()
>             flush_input()
>         else
>             textline()
>         goto loop
> 
> Now, it is get_character() which processes \ commands and so they're
> never seen by the loop above and, consequently, ch will be the first
> character on the line after any of these are processed.

Given your interpretation, this agrees with the logic which I previously
surmised (as to why \fB.test\fP does not produce Bold, since when the
line is parsed it evaluates to the request ".test", etc.) I'm tickled
that my guess is confirmed from so great a height!

> The November 1992 troff's User's Manual has been quoted several times
> but the second paragraph hasn't.  Here's both.
> 
>     1.1. [SNIPPED]

>     Various special functions may be introduced anywhere in the input
>     by means of an escape character, normally \. For example, the
>     function \nR causes the interpolation of the contents of the number
>     register R in place of the function; here R is either a single
>     character name as in \nx, or a two-character name introduced by a
>     left-parenthesis, as in \n(xx.
> 
> `Control lines begin with a control character' is later augmented by
> `Various special functions may be introduced *anywhere* in the input'.
> The emphasis is mine.

I did not originally interpret this as implying that they could be
so introduced without affecting interpretation of the rest of their
context (e.g. interpolating "\fB" without preventing "\fB.test"
being seen as ".test"); I simply interpreted it as "such interpolation
is valid [i.e. correctly parseable) input". This still allows \fB
to hide the "." at the start of the line.

I might now guess [again !] that \[anything] will still allow
"\[anything].test" to be seen as ".test" provided the effect of
\[anything] does not interpolate characters into the input line,
i.e. \[anything] is "silent". 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, nor why "\c.test" and
"\p.test" hide ".test" altogether.

So it's not so simple.

> Why just the font appearance ones?  I'd have thought many more.

Well, by my experiments (see above), the only other one is \R. But
that's on groff: maybe Plan 9 troff is different!

> Werner wrote:
>> For non-compatibility mode, I plan to follow the troff manual, i.e.,
>> "." and "'" must be the first character on an input line to be
>> recognized as control characters *without exception*.
> 
> I think that would be wrong;  once you know the behaviour is
> intentional the manual can be read to match the behaviour.

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!

>> What do other people think?
> 
> In summing up what you appeared to be arguing, Unix troff always allows
> \ commands before . or ' on a line, the User's Manual can be
> interpreted to match, and the structure of the source also backs up
> that it's an intentional feature.  All that's left is to make groff
> work correctly.
> 
> Does this sound like a strong argument?

Indeed it does. The question is, "what's correct?" (see my comments
on the various "\" commands above). It is not necessarily what you
might infer from what you may think is a plausible general principle
(though being able to trust such an inference is a big component
of intuitive understanding of any input language, not just groff).

I'd like to propose a PROJECT.

One of the "baselines" for groff (i.e. what groff documentation
has traditionally been a "diff" of) is the behaviour of "UNIX troff".
As I've argued, it is not clear or unambiguous what this should mean.

Ralph Corderoy has the privilege of access to Plan 9 code. Authentic
though this may be, and derived from original AT&T code as it undoubtedly
is, it may still be a question whether "Plan 9 troff" is the One True
UNIX troff. However, either that or something else must be _deemed_
to be such (it would be good to know what James Clark meant by it,
but I doubt he's all that willing to re-visit that era of his life).

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

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

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.

And, of course, as far as I can I'd be willing to do my best
for such a project.

Now that groff is making such significant advances at the hands
of Werner and other code contributors, this looks like our last
chance to get a clear view of the relationship between groff
and UNIX troff. (Some years ago, I wished I could have taken
this question up in detail with James Clark, but by then he
had already left the scene with a pretty clear statement that
he was no longer interested).

Best wishes to all,
Ted.

--------------------------------------------------------------------
E-Mail: (Ted Harding) <address@hidden>
Fax-to-email: +44 (0)870 167 1972
Date: 28-Aug-01                                       Time: 16:38:57
------------------------------ XFMail ------------------------------