groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: weird \s


From: Ingo Schwarze
Subject: Re: weird \s
Date: Tue, 31 Mar 2020 12:45:21 +0200
User-agent: Mutt/1.12.2 (2019-09-21)

Hi Doug,

Doug McIlroy wrote on Mon, Mar 30, 2020 at 10:53:23PM -0400:

> Thanks for spotting the facts in info, a jungle I rarely
> enter. Especially for groff, for which groff(7) is quite a
> comprehensive reference.
> 
> The difference between \s39 and \s40 is a documented living
> fossil!
> 
> Clearly this dates from the first CAT phototypesetter's limited
> range of point sizes: 6 to 36.  In one of his less brilliant
> moments, Joe Ossanna apparently built that limitation into
> troff's tokenizer: \s ate one digit, or two if the second is
> not more than 3. This was not spelled out in the Troff User's
> Manual, nor did it apply to .ps.  Hidden away as it was, the
> obsolete feature persisted past the arrival of more capable
> typesetters.

Maybe there was a point in history, likely about four decades ago,
when this design mistake could have been fixed.  I have no strong
feelings about the question whether groff should fix it now,
but consider this:

   $ printf 'a\\s39b\\s40c\n' | groff -T ascii | head -n 1        
  ab0c
   $ printf 'a\\s39b\\s40c\n' | 9 nroff | head -n 1               
  ab0c
   $ printf 'a\\s39b\\s40c\n'|/usr/local/heirloom-doctools/bin/nroff|head -n1
  ab0c
   $ printf 'a\\s39b\\s40c\n' | mandoc | sed -n 5p
  ab0c

There is value in compatibility with historical documents, in
particular where the consequences of changing behaviour would be
as ugly as for historical code similar to "\s99 nroff\s0".
Then again, there is also value in avoiding surprising parser
rules, in particular for something as surprising as what \s99 does.

Strong arguments both ways...

> Did the author of groff steal the code from Bell Labs?  Or did
> he merely read the code and preserve the feature in a misguided
> nod to backward compatibility?  Did he find it by experiment?

At least for mandoc, i can answer that:

  https://cvsweb.bsd.lv/mandoc/mandoc.c#rev1.92

So, even today, the rc(1) manual page from plan9 contains "\s10".
Originally, mandoc misparsed that as "\s1\&0" because we thought
that without "(" or "[]", escape sequences would only take a
single-byte argument.  When naddy@ found the issue in 2015 while
trying to read the rc(1) manual page, i consulted the groff manual
how \s is supposed to work, then implemented that behaviour (including
the difference between \s39 and \s40) from the specification.
No code was stolen, not even from groff.  ;-)

Yours,
  Ingo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]