Follow-up Comment #17, bug #67363 (group groff): Hi Russ,
At 2025-08-09T17:52:06-0700, Russ Allbery wrote: > (I'm not sure how to reply to these bug messages that I get because, I > assume, I'm a watcher on the bug. Yes, that's why. > The only addresses offered to respond to are invalid.nore...@gnu.org > and bug-groff@gnu.org, and I'm not sure if either of them correctly > add my message to the bug. I'm copying you directly in this one so > that you don't have to dig it out of the moderation queue. Someone else, Werner or Dave, kindly took care of that while I was napping. :) > Let me know if there's some better place to send the message that will > work more smoothly with the bug system.) You can reply via the web interface at the ticket URL, <https://savannah.gnu.org/bugs/?67363>. To reply via _email_, there are 5 requirements I know of, some of which you may not want to deal with. 1. You must have a Savannah ticket tracker user account. 2. A GPG key must be associated with that account. 3. You must reply to savannah-track...@gnu.org and use a specially crafted "real name" part that includes your numeric user ID. To: XXXXXX-bugs-savannah <savannah-track...@gnu.org> 4. You must include a specially crafted line at the end of the message that encodes your user ID and the ticket number. Braces have to enclose the following. I omit them to try to keep Savannah's mail interpreter from interpreting the line and discarding all of the subsequent message. We'll see how I fared. savane: user = XXXXXX; tracker = bugs; item = YYYYY 5. You must GPG-sign the message using the key that Savannah has on file for your user account. Support for email-transported replies to Savannah tickets is a relatively new feature, a year or two old. Dave Kemper and I seem to have done some service as its guinea pigs. I understand if you don't want to bother with these requirements. > "G. Branden Robinson" <invalid.nore...@gnu.org> writes: > >> You might want to add > >> .if n .nr HY 0 > >> to podlators-generated man pages. > > Okay, thanks. I'll try to get a new release out with that change soon. No rush on my account--you'll probably manage to do that before I manage to get _groff_ 1.24.0 finalized. > Currently, I just put .nh immediately after .TH and assume that it > will persist. It will persist until overridden by the document itself, which podlators won't do. As I noted earlier, one of the problems is that alterations to adjustment and automatic hyphenation persist too long when formatting multiple documents in one run. For _man_(1) users, that's not a practical problem because _man-db man_, at least, forks a new _troff_ process for each document to be rendered. Among the minority of users who ever request multiple documents from _man_(1) with one command, much muscle memory tends to develop around the pattern of hitting "q" (rather than _less_(1)'s ":n") to move to the next document. But if you want to generate a PDF compilation of dozens or hundreds of man pages, you have to start sweating these matters (or the _man_(7) package author has to). >>> I think the important part for podlators going forward, given this >>> behavior, is to make sure that the ".if n .ds AD l" line stays in >>> the preamble (in other words, before .TH) so that groff can >>> reassert user preferences at .TH and not be confused with (3). >>> That's easy enough (and natural) to do. > >> That should not be necessary, and in fact I expect such an early >> operation to be ignored. > > Hm, I think there's some confusion here. Right now, the released > version of podlators puts the line: > > .if n .ds AD l > > right before the .TH macro, and this works correctly with groff > 1.23.0. Whoops--I'm sorry, I mentally flagged that remark to double-check modern (not Debian bullseye) podlators output, and forgot to go back and check. Because, uh, my message got so long that my brain cache spilled. :-| I see it comes at the end of _podlators_'s "preamble". https://github.com/rra/podlators/blob/87dd36c591ffaca20e30bffe9b8d165dc49aa4ac/lib/Pod/Man.pm#L1624 > Are you saying that this line needs to move to somewhere else with > groff 1.24.0? Yes. > Where, precisely? Anywhere after the `TH` call and before the first line break in body text that would occur in the rendered document. As you note, people use terminals of widely disparate widths; once filled text begins, the location of a break is hard to predict (until a paragraph ends), so the safe things to do are to put it either (1) right after the `TH` call, or (2) right after the first `SH` call ("Name" in English-language pages), since a well-formed man page puts no filled text before that point. We advise people to put stuff like page-local macro definitions a bit later, even. _groff_man_style_(7): ... Further, it is wise to define such page‐local macros (if at all) after the “Name” section to accommodate timid makewhatis(8) or mandb(8) implementations that easily give up scanning for indexing material. But that degree of procrastination won't achieve your aim here, if the page's topic list and description are sufficiently long to automatically break. Also, the foregoing quoted advice is a bit of folk wisdom that I'm sure was warranted at some time in the past, but may no longer be. I haven't personally observed such a failure in any _man_ implementation available to me.[A] (But neither have I looked very hard for one.) On the gripping hand, decades of perlpod-generated man pages in the field have presumptively forced some robustness into _makewhatis_(8) and _mandb_(8) implementations. > Will it still work correctly if moved with groff 1.23.0? Yes, for the reason presented above. If you're curious, here are my tests for this stuff. https://cgit.git.savannah.gnu.org/cgit/groff.git/tree/tmac/tests/an_adjustment-mode-preserved-after-paragraph-tag.sh?id=ffcb765b4526b16c4ddc940ddd24d9c924af4c9e https://cgit.git.savannah.gnu.org/cgit/groff.git/tree/tmac/tests/an_adjustment-mode-restoration-works.sh?id=ffcb765b4526b16c4ddc940ddd24d9c924af4c9e https://cgit.git.savannah.gnu.org/cgit/groff.git/tree/tmac/tests/an_hyphenation-mode-restoration-works.sh?id=ffcb765b4526b16c4ddc940ddd24d9c924af4c9e I see that I could add one for restoration of the document's hyphenation mode preference after its alteration with requests and a subsequent "paragraph reset". >> Yes, as noted above, > >> .if n .nr HY 0 > >> Is probably what you want, and moreover should work with every >> _groff_ in the world even in old deployments. It's an old >> feature.[2] > > Where should I put this in the document? I'd put it adjacent to the `.if n .ds AD l` control line--before or after doesn't matter. If you want to cluster your operations by theme or purpose, as with... .na .if n .ds AD l .nh .if n .nr HY 0 ...that's fine, too. >> [2] The code comments concede that the `HY` register isn't supported >> everywhere. That's true, but Solaris 10, DWB 3.3, and Seventh >> Edition Unix _troff_s are all historical implementations, and >> Plan 9 from User Space is a something of a niche exhibit--which >> might nevertheless accept a patch from me if I submitted one.[3] >> _mandoc_ doesn't support it, but doesn't need to. > > Presumably I should both define HY *and* continue to use the .nh > directive to account for those systems. Very much, yes. > Everything I write below this point can be safely ignored entirely. It > has no relevance to the technical discussion or this change in > particular. I'll reply to those parts separately. :) Regards, Branden [A] I routinely test _groff_'s trunk, the past 3 _groff_ releases, DWB 3.3 _troff_, and Heirloom Doctools _troff_. I occasionally test Plan 9 from User Space _troff_ and (thanks to SIMH) Seventh Edition Unix _troff_. I rarely test _neatroff_ (mainly because its build system poorly fits my personal habits). _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?67363> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/
signature.asc
Description: PGP signature
