[bug #63133] [pdfroff] throws warning on any document if -ww given

[Keith Marshall]

Follow-up Comment #3, bug #63133 (project groff):

[comment #2 comment #2:]
> Long story short, the `.C` register didn't work for some of the use cases
people had for it, including the one seen above.
Yep.  The interaction between compatibility mode and '.C' is kind of tricky
... when compatibility mode is on, it needs to be interpolated using the
'\n(.C' syntax, because the '\n[.C]' syntax isn't "compatible":

$ printf '.cp 0\n.tm .C = \\n[.C]\n' | groff -ww > /dev/null
.C = 0
$ printf '.cp 1\n.tm .C = \\n[.C]\n' | groff -ww > /dev/null
.C = troff: <standard input>:2: warning: number register '[' not defined
0.C]
$ printf '.cp 1\n.tm .C = \\n(.C\n' | groff -ww > /dev/null
.C = 1

Interaction with the '.do' request compounds the trickiness:

$ printf '.cp 1\n.do tm .C = \\n[.C]\n' | groff -ww > /dev/null
.C = 0
$ printf '.cp 1\n.do tm .C = \\n(.C\n' | groff -ww > /dev/null
.C = 0

It appears that the '.do' takes effect *before* the remainder of the request
line, (and in particular, the '\n(.C' evaluation), is parsed.  Thus, within
the scope of '.do', '\n(.C' must *always* evaluate to zero.  This isn't made
particularly clear, in the relevant groff documentation.
> This went unnoticed for a long time, I think, because relatively few people
tried to render many groff man pages in series using a single invocation of
the formatter.
Or ... perhaps more likely ... few people use groff directly, to render
manpages, and even those who may have done so didn't think to add the '-ww'
option?
> > Please note that this wider issue is not even related to pdfroff:
> > 
> > $ groff -ww -man src/roff/groff/groff.1 > /dev/null
> > troff: src/roff/groff/groff.1:25: warning: number register '.cp' not
defined
> > 
> > Does this merit its own bug report?
> 
> I don't think so.  It was a deliberate feature change.  I infer that you're
running the above commands using groff 1.22.4
Yes; it's what is installed by default, by the Manjaro derivative of Arch
Linux, (which is my current distro of choice).
> (else you wouldn't get the diagnostic message, which also hasn't been worded
that way since before commit 31e8ff9daf on 30 June 2021.
Fair enough.  I noticed it when formatting up-to-date pdfroff.1.man with
similarly up-to-date pdfroff, and with '-ww' in effect, per this ticket, but
underpinned by the system-native groff installation.
> On another subject:
> 
> > in my own groff-pdfmark development fork
<https://osdn.net/users/keith/pf/groff-pdfmark/scm/blobs/tip/Makefile.in>.
> 
> In bug #63590, you expressed disinterest in maintaining pdfmark in the groff
source tree.
I no longer feel comfortable committing directly to the groff repo, following
the debacle when you deleted a published branch ...
> Would you prefer to make your OSDN the official pdfmark resource?
so yes, I would prefer to keep control of my own development tree.
> I don't think it would do anyone any good for contrib/pdfmark to bit-rot in
groff's contrib.
Agreed.  I have, indeed, added significant new content to pdfmark.pdf, (via
pdfmark.ms), and some pdfroff enhancements, which are not now included in
groff's contrib/pdfmark tree.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?63133>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/