Re: [Groff] surprise, surprise

[Werner LEMBERG]

> The Plan 9 source (which is essentially Bell Labs troff) 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.

GNU troff basically has the same structure, but now escapes like \f or
\s *do* produce a token seen by the loop if not in compatibility mode.

> `Control lines begin with a control character' is later augmented by
> `Various special functions may be introduced *anywhere* in the
> input'.

But where is written that such `special functions' are transparent if
the beginning of the line is considered?  I think you are deducing too
much here.

> > Well, I'll save you the trouble: the ones which are transparent for
> > "." are \f, \s as above, \H'N' (font height N points), and \S'N'
> > (slope by N degrees) -- in fact, those which have to do with font
> > appearance.
> 
> Why just the font appearance ones?  I'd have thought many more.

Previousy, only these escapes (and \R) didn't return to the main loop
function (process_input_stack).  I've changed that now.

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

In compatibility mode, groff still behaves similar to UNIX troff now.

> > 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).
> 
> I'd expect all Bell Labs derived version to behave like this; it's
> not some `start of line' flag being erroneously left set which one
> licensee may have fixed but a result of the code structure.

I still consider this as a bizarre feature *due* to the code
structure.  Maybe it was too complicated to fix it.  At least in groff
it was about 30 lines to make it work as expected.

> In summing up what you appeared to be arguing, Unix troff always
> allows \ commands before . or ' on a line, [...]

This is simply not true.  In case the escape expands to something
(e.g. \n[yr]), "."  or "'" is no longer specially handled.

> Does this sound like a strong argument?

Not for me, sorry.


    Werner