Re: [Groff] LL Usage in an-old.tmac Incompatible with man Program on GNU/Linux

[Keith Marshall]

On Wednesday 17 August 2005 4:22 pm, Werner LEMBERG wrote:
> > This uses `man-db', rather than `man'; but notice that it too
> > attempts to inject a `.ll' request into the pipe.  This is
> > presumably to satisfy non-groff implementations of `nroff', for
> > which the accompanying `tmac.an' probably doesn't comprehend this
> > `LL' usage; indeed, isn't the `-rLL=132n' incompatible with standard
> > UNIX nroff?  (I'll check on the Solaris box at work tomorrow, to see
> > what it's `tmac.an' does).
>
> Hmm, it's not incompatible, but classical troff doesn't have -r, so it
> should be ignored.

If this were true, I would expect classical troff to choke on an `illegal 
option', rather than to simply ignore it.  However, as Tadziu has already 
pointed out, classical troff does support `-raN', where `a' is a single 
character register name, but it does not support groff's extended syntax, 
which allows for arbitrary length register names.  Thus, classical troff will 
interpret `-rLL=132n', for example, as an assignment for a register named 
`L', with a value of `L=132n', which is unrecognisable as a numeric value, 
and so becomes zero.  In this sense, the `-rLL=132n' syntax is incompatible 
with classical troff, since it is not interpreted as intended, or indeed, as 
one might expect.  This is in no way intended as a criticism of groff's 
extended syntax, which IMO is perfectly natural and obvious; it is merely an 
observation that such extensions, while being beneficial, do require us to 
sacrifice backward compatibility.

> > > >   .ie n .nr LL 78n
> > > >
> > > >   .ll \\n[LL]u
> > > >
> > > > override the injected `.ll' request, forcing an output line
> > > > length of 78n, regardless of the width of the console display.
> > >
> > > This is the only way to provide a default width.
> >
> > Accepted, but what's wrong with nroff's own default width?
>
> groff's nroff use the same default width as all other devices, namely
> 6.5i, which is 65 columns.  IMHO it's the job of the macro package to
> set a suitable default width (as does -ms, for example).

A reasonable opinion, but does it need to be quite so cavalier about it, as 
the current implementation appears to be?

> > > > Looking in an-old.tmac, it would seem that the LL register is
> > > > mostly redundant;
> > >
> > > I won't remove it -- I want orthogonality with other macro
> > > packages.
>
> BTW, I've looked into the Solaris `an' macro file and found this in
> the `TH' macro:
>
>   .ll 6.5i
>   .nr LL \\n(.l
>
> This basically means that you can't modify the width of man pages.
> Does `man' on Solaris really adjusts the width of man pages to a
> changed terminal width?

Yes, I found the same.  And no, Solaris' `man' doesn't vary the display width 
to suit the screen -- quite irritating, IMO, when half the width of a wide 
screen is wasted by text constrained to a 65 character width.

> > No problem -- I'll keep my patched version in site-tmac, so I can
> > have the behaviour I want.
>
> It might be a good idea to report this to the `man' maintainers so
> that they can insert a proper `-rLL=...' call similar to `man-db'.

I just merged Federico Lucifredi's man-1.6 release into my MinGW ported 
codebase -- quite easy, with the help of CVS :-)  I notice that this now 
injects a `.nr LL ...' request into the pipeline, to achieve the same effect. 
However, this release is too new -- less than two months old -- to have made 
it into any current distro, so there may yet be justification for adding some 
form of backward compatibility support for earlier `man' versions into groff. 
I fully respect your right to reject any patch, and your reasons for doing so 
in this case, but would you consider a variation, accompanied by a manpage 
update, implementing the following behaviour?:

  - If the LL register is defined, prior to the invocation of TH, then honour 
its setting -- this is exactly as current behaviour, and would take 
precedence over any other line length initialisation method.

  - If LL is not defined, but a prior `.ll' request has changed the line 
length from the nroff/troff default, then initialise LL to match the adjusted 
line length -- this would be an extension to present behaviour; it would be 
effective only if the value of \n[.l] differs from the nroff/troff default, 
at the time when TH is invoked, and could be restricted to apply in nroff 
only, but probably makes sense to allow it for troff as well.

  - If neither of the above applies, then initialise LL to 78n for nroff, or 
6.5i for troff, exactly as present behaviour.

If this would be accaptable, I can provide a suitable patch.

Best regards,
Keith.