[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Groff] surprise, surprise
From: |
Werner LEMBERG |
Subject: |
Re: [Groff] surprise, surprise |
Date: |
Tue, 28 Aug 2001 22:48:11 +0200 (CEST) |
> 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
- Re: [Groff] surprise, surprise, (continued)
- Re: [Groff] surprise, surprise, Ted Harding, 2001/08/28
- Re: [Groff] surprise, surprise, Werner LEMBERG, 2001/08/27
- Re: [Groff] surprise, surprise, Ralph Corderoy, 2001/08/28
- Re: [Groff] surprise, surprise, Ted Harding, 2001/08/28
- Re: [Groff] surprise, surprise, Ralph Corderoy, 2001/08/28
- Re: [Groff] surprise, surprise, Werner LEMBERG, 2001/08/29
- Re: [Groff] surprise, surprise, Werner LEMBERG, 2001/08/29
- Re: [Groff] surprise, surprise, Clarke Echols, 2001/08/28
- Re: [Groff] surprise, surprise, Jon Snader, 2001/08/28
- Re: [Groff] surprise, surprise, Ralph Corderoy, 2001/08/28
- Re: [Groff] surprise, surprise,
Werner LEMBERG <=
- Re: [Groff] surprise, surprise, Ralph Corderoy, 2001/08/26
- Re: [Groff] surprise, surprise, Werner LEMBERG, 2001/08/27
- Re: [Groff] surprise, surprise, Andrew Koenig, 2001/08/27
- Re: [Groff] surprise, surprise, Werner LEMBERG, 2001/08/28
- Re: [Groff] surprise, surprise, Ralph Corderoy, 2001/08/28
- Re: [Groff] surprise, surprise, Clarke Echols, 2001/08/28
- Re: [Groff] surprise, surprise, Werner LEMBERG, 2001/08/29
- Re: [Groff] surprise, surprise, Werner LEMBERG, 2001/08/29
- Re: [Groff] surprise, surprise, Ted Harding, 2001/08/29
- [Groff] #ifdef WIDOW_CONTROL???, Sigfrid Lundberg, Netlab, 2001/08/30