[looping in groff list due to musings on its development] Hi Alex,
At 2025-12-10T00:18:32+0100, Alejandro Colomar wrote: > On Tue, Dec 09, 2025 at 03:51:49PM -0600, G. Branden Robinson wrote: > > I'm the GNU maintainer of groff and the author (instigator?) of the > > `soquiet` request. Your patch isn't wrong, but I must point out > > that the `soquiet` request is new to groff 1.23.0 (which isn't that > > new anymore--it was released in July 2023). > > > > > -.so man7/groff_man.7 > > > +.soquiet man7/groff_man.7 > > I'm not yet convinced that this is beneficial. I'd like to first hear > [Colin]'s opinion of my proposal of not following .so in man(1) > unnecessaily. Colin with one ell. Watson != Funk. :) > > If Alex applies this, it means the page redirection[1] will stop > > working _where it had been before_ for any systems using groff > > 1.22.4 or older. > > Would it be possible to implement a .soquiet fallback as you did with > .MR in Debian? Yes, but it would be ugly, because it would require bitwise arithmetic on the value of the `.warn` register, to temporarily mask off the position in this bit vector that enables warnings in category "file". Since the *roff language doesn't have bitwise arithmetic operators, this means manipulating large, mysterious integers. https://www.gnu.org/software/groff/manual/groff.html.node/Warnings.html#Warnings I've been taking examples of this sort of bit fiddling _out_ of groff's corpus. See, e.g., <https://savannah.gnu.org/bugs/?57583>. Not long ago, I sketched a design for an extension to GNU troff syntax for requests like `warn` and `cflags` that would enable greater expressiveness.[1] If anyone ever gets around to implementing that, we could retire the `soquiet` and `msoquiet` requests from the formatter language, demoting them to "compatibility macros" in some "tmac" file that would probably be loaded by default for one release, then not. Because then you could simply say the following (and this is in fact almost how I'd write `soquiet` as a macro). .do nr saved-warn \n[.warn] .do warn -file .so man7/groff_man.7 .do warn \n[saved-warn] This is even completely portable to AT&T troff. (Maybe "compat124.tmac" would be automatically loaded by "troffrc" in groff 1.25, but not in groff 1.26. But we'd keep shipping "compat124.tmac" forever; as a side effect, this scheme would tend to drive documents in the direction of either (1) keeping pace with developments in the formatter, (2) declaring their demand for an old version, or (3) using a "compatible subset of the language", as AT&T troff documents largely already do when interpreted with GNU troff.) All seem like sound practices to me, appropriate to different audiences. Similarly, if we ever get the string iterator I've spent years grumbling about,[2] a _whole bunch_ of string-related requests could move to such a "compat" macro package, and a several contemplated new ones could be implemented in a new auxiliary package, say, "string.tmac".[3] > > If Alex wants to make the Linux man-pages require groff 1.23.0 or > > later (there's been no subsequent release, but I'm working on > > it[2]), that's fine with me, but such a decision should be announced > > so that distributors of man-pages packages can judge whether they > > need/want to increment the versioning of their package dependencies > > accordingly. > > Actually, this will happen sooner or later, and the exact date depends > more on you than me. Yup, I've just got to learn how to document my inscrutable sed(1) incantations to your satisfaction. ;-) > MR.sed is coming eventually. :) Aye, and I'll be a happy guy when it does. > I'd prefer if Ingo would release a new version of mandoc(1) before > that happens, but I'm not going to wait forever. He told me he might > release around the end of 2025 or begining of 2026, but that it wasn't > certain. We'll see. Yeah, the landing of groff 1.23.0 in OpenBSD seems to be a bit stuck as well. :( https://github.com/ischwarze/groff-port/commits/1.23/ Part of the problem there is, I suspect, multiple disagreements between Ingo and me over what constitutes a "regression" in groff. In my opinion, he managed, in mandoc(1)'s test suite, to explore the *roff language aggressively (that's a good thing), to the point that he discovered undefined behavior. And also a perhaps under-appreciated major difference in AT&T troff and GNU troff syntaxes. Regards, Branden [1] https://lists.gnu.org/archive/html/groff/2025-12/msg00007.html [2] https://savannah.gnu.org/bugs/?62264 [3] https://lists.gnu.org/archive/html/groff/2024-11/msg00044.html
signature.asc
Description: PGP signature
