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/