Re: [Groff] surprise, surprise

[Ralph Corderoy]

Hi,

(I'm replying to several messages in one go here.)

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

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

    1.1. Form of input. Input consists of text lines, which are
    destined to be printed, interspersed with control lines, which set
    parameters or otherwise control subsequent processing. Control
    lines begin with a control character-normally . (period) or '
    (single quote)-followed by a one or two character name that speci-
    fies a basic request or the substitution of a user-defined macro in
    place of the control line. The control character ' suppresses the
    break function-the forced output of a partially filled line-caused
    by certain requests. The control character may be separated from
    the request/macro name by white space (spaces and/or tabs) for
    aesthetic reasons. Names should be followed by either space or
    newline. Control lines with unrecognized names are ignored.

    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.

Ted wrote:
> Well, I'll stop there; but it does look as though you could use a lot
> of different "\..." escape sequences without "hiding" the "." at the
> start of the line.
>
> 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.

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.

Ted wrote:
> 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.

Also, IIRC Kernighan said that this area of C code was written by
translating the PDP assembler, hence all the labels and gotos.  They're
still there and I think this is a original feature of the PDP version.

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

Completely agree.  This is troff.  Long live troff!  :-)

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


Ralph.