[restricting to list since I'm interposing myself between two other people]
At 2026-01-19T15:30:34+0100, Ingo Schwarze wrote: > Dave Kemper wrote on Mon, Jan 19, 2026 at 08:07:49AM -0600: > > On Mon, Jan 19, 2026 at 5:04 AM Ingo Schwarze <[email protected]> > > wrote: > > >> I had to look up what \n[.y] even is, and now i find it weird that > >> this register exists at all. That's not something documents should > >> access or depend on. > > > That would be true if no features of groff ever changed from one > > release to another, or if no bugs were ever fixed that might need > > workarounds in older groffs. > > Even in software configuration systems / build systems, checking > version numbers is by far the worst approach for making decisions how > to build. If true, then SemVer, to which I referred earlier today,[1] is doomed. Funny, though. The minute developers do something radically insane like not trusting version numbers, and instead implement a system of empirical tests of the host system for standard and/or correct behavior at build time so that their prerequisites are explicit and well-founded, other developers come along and viciously derogate that same project as "bloatware".[2][3] It seems that everybody who has a beef with GNU Autoconf addresses their grievance in one of two ways: 1. They join the SemVer cargo cult, abandon dynamic shared objects, statically link everything, juice the revenues of RAM and SSD vendors, and open themselves proudly to year after year of "leftpad" debacles. 2. They reinvent GNU Autoconf, but couple it tightly with their replacement for make(1), creating an even bigger and more complicated build system.[4][5] And they get promoted, because it's really cool to build cathedrals--"it's like systemd, but for build systems!" And their web sites look sooooo fetch. Okay, there's a third way, popular with people who develop for one kind of host platform only. 3. "Works for me. **** you." And that is in fact the most popular approach among commercial OS vendors. > In a document intended to be typeset, inspecting version numbers > in order to work around bugs or missing features in old typesetter > versions feels just insane. I think it's okay to give _document_ authors sufficient tools to work around host/environment issues in an easy way, even if that's a bit ad-hoc. Not everybody wants to surround their document with a sophisticated, feature-probing build system, or "lift" their document so as to essentially write it in a meta-macro language, as I've done with "tmac/groff_man.7.man.in" for other reasons.[6] > Simply write the document for a given minimum typesetter version and > be done with it. _Often_ the best choice, and the first I'd recommend. But sometimes people come back and say, "actually, we can't do that, because...". It's nice to have an answer for that--especially when one's already in groff's toolkit and requires no new development effort. > Or if you are maintaining a macro set, each version of the macroset > you release should simply be designed for a minimum typesetter > version. I find this prescription more defensible, and it is in fact what most of groff's own ("full-service") macro packages do.[7][8][9][10][11][12] Even your least favorite auxiliary macro package, hdtbl, now does this.[13] > The only macrosets where document portability matters, including > to older typesetters, are man(7) and mdoc(7) - and nobody uses .y > there, and it would be insane if anyone did. groff uses `.y`; we've done so for almost a quarter-century. $ git blame 1.22.3 -- tmac/an-old.tmac | sed -n '46,47p' ed63b0ae76 tmac/an-old.tmac (Werner LEMBERG 2002-07-07 08:10:59 +0000 46) .if (\n[.x]\n[.y] < 118) \ ed63b0ae76 tmac/an-old.tmac (Werner LEMBERG 2002-07-07 08:10:59 +0000 47) . ab You need GNU troff version 1.18 or higher to run this version of man! $ git blame 1.22.3 -- tmac/doc.tmac | sed -n '60,61p' ed63b0ae76 tmac/doc.tmac (Werner LEMBERG 2002-07-07 08:10:59 +0000 60) .if (\n[.x]\n[.y] < 118) \ ed63b0ae76 tmac/doc.tmac (Werner LEMBERG 2002-07-07 08:10:59 +0000 61) . ab You need GNU troff version 1.18 or higher to run this version of mdoc! > But to return to the topic of the discussion, both Colin and myself > hope for consistent version numbers in release tarballs (and both > of us admitted that mixups of version numbers are easy to work > around in build systems, so these are not the worst issues > imaginable). Anyway, i'm not really asking for deletion of the .y > feature, nor should it stand in the way of consistent version > numbers in tarballs. With that much, I agree. My mistake. I'll fix it in the next archive. Regards, Branden [1] https://lists.gnu.org/archive/html/groff/2026-01/msg00067.html [2] https://neurocline.github.io/dev/2017/05/19/autools-must-die.html [3] https://queue.acm.org/detail.cfm?id=2349257 [4] https://cmake.org/ [5] https://mesonbuild.com/ [6] I use m4 to generate groff_man(7) and groff_man_style(7) from a single source document to reduce the risk of content desynchronization or staleness. [7] https://cgit.git.savannah.gnu.org/cgit/groff.git/tree/tmac/an.tmac?id=7dcc8b53f944178d91b0f25b67ac32d4f98d9049#n32 [8] https://cgit.git.savannah.gnu.org/cgit/groff.git/tree/tmac/doc.tmac?id=7dcc8b53f944178d91b0f25b67ac32d4f98d9049#n56 [9] https://cgit.git.savannah.gnu.org/cgit/groff.git/tree/tmac/s.tmac?id=7dcc8b53f944178d91b0f25b67ac32d4f98d9049#n26 [10] https://cgit.git.savannah.gnu.org/cgit/groff.git/tree/contrib/mm/m.tmac?id=7dcc8b53f944178d91b0f25b67ac32d4f98d9049#n42 [11] https://cgit.git.savannah.gnu.org/cgit/groff.git/tree/contrib/mom/om.tmac?id=7dcc8b53f944178d91b0f25b67ac32d4f98d9049#n47 [12] The exception is me(7). Because we maintain its original BSD license, James Clark apparently thought it would be polite to ensure that users of BSD ditroff (which was commercial), or Seventh Edition Unix troff (which wasn't), could use it if they wanted to. That tradition has not been difficult to maintain, and about a year ago, at Dave's prompting, I went through and made sure the package still worked in compatibility mode, adding `do` requests and control structures where they had been missing. See, variously, the following commits. ddc3ab65aba5d71964811185dce6b78bc401f8e5 af34450ffc7cf157627e81ffed043e412bd18620 a7853c5b5bb975a6e058238405bb0080a9a4a19a bead61d87ec685c61f8ff8257da112240d5b6b8b [13] https://cgit.git.savannah.gnu.org/cgit/groff.git/tree/contrib/hdtbl/hdtbl.tmac?id=7dcc8b53f944178d91b0f25b67ac32d4f98d9049#n28
signature.asc
Description: PGP signature
