Re: [Groff] surprise, surprise

[Ted Harding]

I'd like to sum up my own current view of this business.

I first realised that \fB (etc) was transparent for recognition
of "." at the start of a line, years ago when I was writing
(in groff) some notes on usage for other people to refer to.

Initially, I adopted the logical reading of the troff User's
Manual, that "." had to be the very first character on a line
in the input text. So I wrote input like

  \fB.ps 12\fP sets the font size to 12 points

Then, when I looked at the output, I realised that this interpretation
was wrong. So I just shrugged my shoulders and decided that,
in his wisdom, James Clark had introduced the "transparency"
(not realising then, as has emerged over the last few days, that
even UNIX troff, at least in some versions, behaves similarly).
So I did the safe thing, which was to write

  \fB\&.ps 12\fP ...........

Whatever the rights or wrongs of the way things currently work
may be, I don't regret having to take the little extra trouble
to force the interpretation I want. The logic of [g]troff is
already sufficiently intricate; and in any case if I ever wanted
to remove the \fB...\fP I would then have to insert the "\&"
anyway, so it may as well go in in the first place. And the

  \fB\&.ps 12 \fP ..........

would work in any version of troff, whether transparent to
"\fP" or not.

However, that being said, I experienced at the time the slightly
shocked surprise people have been expressing in this current
discussion.

I think the issue before us is the following.

IF it is cast-iron definite that "UNIX troff" (whatever that
may precisely mean) IN PRACTICE (i.e. when the software is run)
treats \fB.ps 12\fP ... as NOT having a "." at the beginning
of the line, then there is a cast-iron case for groff (at least
in compatibility mode) to do exactly the same thing. This is
then 100 per cent compatible wih the literal interpretation
of the troff User's Manual.

However, if (despite the User's Manual) there are at least some
versions of "UNIX troff" which do it the other way (i.e. "\fB"
is transparent), then (given the long-standing ambiguity as
to what JC meant by "UNIX troff") I think we should stick
to the present situation (though there is a possibility of
anomalous behaviour in certain examples which may need sorting
out). The logic of this point of view is that "UNIX troff" is
already in contravention of the strict interpretation, and
in that case what needs correction is the Manual itself, in
that it does not cover this case.

While I have every admiration for the concise (though by no
means always easily-penetrable) clarity of Ossanna & Kernighan's
"Troff User's Manual", I have doubts about its completeness.
For instance, with reference to Clarke Echol's examples
of initial "space" causing a break, in my copy of the User's
Manual it simply says:

  ...; initial spaces also cause a break.

and I find I have added the note "and the space is output".[**]
There are quite a few little details of this kind which are not
explicit, though _probably_ but by no means _certainly_ implied
by the "logic"; and, if you like, I classed the realisation
that "\fB" was transparent as yet another instance of something
which hadn't been mentioned which didn't turn out the way you'd
literally expect. So, with due respect, I'm not pre-disposed to
treating the User's Manual as a strict immutable text to be
interpreted absolutely literally, even for UNIX troff.
[**] ... the point being, that while the UM says that the space
     causes a break, it doesn't say whether or not that is its
     sole function and it is then discarded. As it turns out,
     it isn't; but you have to find out by trying it.

Which brings me back to the big IF above. If, as a matter of FACT,
"UNIX troff" _always_ behaves according to the literal interpretation,
then let groff do the same at any rate in compatibility mode.

If not, then we must accept that the User's Manual is a bit fuzzy
on certain issues, at any rate in the context of the somewhat
fuzzy meaning of "UNIX troff" itself. In that case, I think we
have some discretion, which we should use in the way which is
of most practical use. And, as I explained above, if you adopt
a certain view of how you should write troff input (specifically,
making your intentions explicit in the input and therefore
independent of implicit "logic"), then there should not be too many
such issues anyway. In fact (though it's a product of having
become used to the situation) I think it is simpler to make
a small increment to the documentation which says "\fB ..."
are transparent at the beginning of the line for recognition
of "." at the start of the line", than to make radical changes
which -- in the end -- may turn out to be incomaptible with
"UNIX troff" anyway!

What do other people think?

Ted.

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