Re: .LR macro

[Ingo Schwarze <schwarze@usta.de>]

Hi Anthony, hi Kristaps,

Kristaps Dzonsons wrote on Wed, Dec 29, 2010 at 10:47:26AM +0100:
> Anthony Bentley wrote:

>> This shows up in the Plan 9 manpage mk.1:
>>
>> .PP
>> Seemingly appropriate input like
>> .B CFLAGS=-DHZ=60
>> is parsed as an erroneous attribute; correct it by inserting
>> a space after the first
>> .LR = .
>> .PP
>>
>> Output from Plan 9 troff:
>>
>>    Seemingly appropriate input like CFLAGS=-DHZ=60 is parsed as an
>>    erroneous attribute; correct it by inserting a space after the first
>>    `='.
>>
>> Mandoc cuts off the last bit:

Well, it doesn't know the .LR macro, as you see with -Tlint:

  ischwarze@isnote $ mandoc -Tlint LR.1  
  LR.1:7:2: ERROR: skipping unknown macro: .LR = .

>>    Seemingly appropriate input like CFLAGS=-DHZ=60 is parsed as an
>>    erroneous attribute; correct it by inserting a space after the first
>>
>> OpenBSD's (ancient) groff displays the same as mandoc.

And so does groff-1.20.1.

> So the plan9 -man specification,
> 
>  http://swtch.com/usr/local/plan9/tmac/tmac.an ,
> 
> documents `LR' pretty much as you label it.  This is easily
> implemented.  But the plan9 man(7) page,
> 
>  http://swtch.com/plan9port/man/man7/man.html ,
> 
> lists `LR' as an alternating monospace-roman (like `BR' and friends)
> font trigger.  This is also easily implemented.

The Plan9 manual is not sorted very well, but it says, scattered
around four different places of the page:

  DESCRIPTION

  Except in .LR and .RL requests, any text argument denoted t in the
  request summary may be zero to six words.
  [...]
  The fonts are:
  [...]
  L:  also the constant width font.  In troff L=B; in nroff arguments
      of the macros .L, .LR, and .RL are printed in quotes; preferred
      only where quotes really help (e.g. lower-case literals and
      punctuation). 
  [...]
  REQUESTS
  [...]
  .LR t   no   Join 2 words of t alternating literal and Roman.
  [...]
  .RL t   no   Join 2 or 3 words of t alternating Roman and literal.

So i guess this is clear enough.

[...]
> Working with "the other troffs" isn't a priority for mandoc,

Perhaps not yet, but the better mandoc becomes, the more
important will compatibility issues be.  So i'm very happy
about anybody who can tell us about legacy systems!

> but I'm happy to at least have COMPATIBILITY notes regarding the
> others so that we can later work in the biggest offenders.

In this case, the following conditions hold:

 * The feature is documented and used in one legacy system.
 * It doesn't collide with any modern system known to us.
 * it is very easy to implement.

Thus, i see nothing wrong with adding it to mandoc.
In particular since we are supporting man(7) mostly for compatibility
with legacy manuals, anyway, and discourage writing new stuff in man(7),
so there is little risk of people developing bad habits by having
a choice of non-standard features.

Yours,
  Ingo
--
 To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv