[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Groff] LL Usage in an-old.tmac Incompatible with man Program on GNU
From: |
Keith Marshall |
Subject: |
Re: [Groff] LL Usage in an-old.tmac Incompatible with man Program on GNU/Linux |
Date: |
Sat, 20 Aug 2005 09:11:03 +0100 |
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.