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

[G. Branden Robinson]

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

[comment #3 comment #3:]
> [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.

I have tried to clarify it for groff 1.23.

https://git.savannah.gnu.org/cgit/groff.git/tree/man/groff_diff.7.man?h=1.23.0.rc3#n5079

https://git.savannah.gnu.org/cgit/groff.git/tree/man/groff.7.man?h=1.23.0.rc3#n5510

https://git.savannah.gnu.org/cgit/groff.git/tree/man/groff.7.man?h=1.23.0.rc3#n5541

> > 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?

The reason I noticed it is because when batch-rendering man pages, some got
formatted incorrectly because the incorrect saved value of compatibility mode
was used.  That would generally be much more noticeable than a warning which
is off by default and even if enabled by the user, is typically discarded by
man(1), as you note.

[...]
> > 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 ...

For which I apologized, but if you object to published branches being deleted
even _with_ notice, then, yes, it seems your development preferences and the
groff project's
<https://lists.gnu.org/archive/html/groff/2021-11/msg00015.html> have diverged
and will do so again.  (After about a year, I deleted the "tmp-mail-fail"
branch that I created to work around groff-commit reflector problems.)

> > 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.

Okay.  I will update groff's copy of pdfroff(1) shortly to point to your site,
advising users of the move.  I will also withdraw the contrib/pdfmark
directory itself in the next development cycle--I feel it is too disruptive a
change at present (on our 3rd release candidate for 1.23.0.)  (The man page
update can go in before final, of course.)

Thank you for your contributions.


    _______________________________________________________

Reply to this item at:

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

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