Follow-up Comment #7, bug #63827 (project groff): [comment #5 comment #5:] > [comment #3 comment #3:] > > [comment #2 comment #2:] > > > ... > > > More importantly, my simple implementation relies on the '!d' > > > conditional, which I suspect may be groff-specific, (is it?), > > > > Yes. Subsection "Conditional expressions" of groff_diff(7) covers > > it, and the other extensions. > Thanks, but there is no such subsection, in the version of groff_diff(7) on my Manjaro (Arch Linux) system.
I'm sorry, I didn't mention that I was referring to the Git version, which is what I use every day. The subsection has been present since commit 097b3c6c4e <https://git.savannah.gnu.org/cgit/groff.git/tree/man/groff_diff.7.man?h=097b3c6c4e> in May 2020. > The information is there, but not so easily found. In any event, I had been perusing 'info groff', which -- again in the installed version -- does not make it clear that '.if d...' is a groff extension, at the point where the conditional operators are described. You're right, groff's Texinfo manual generally doesn't dwell on what is or is not a GNU extension. That was the style it had when Trent and Werner stopped working on it, and I've preserved that aspect except for deeper syntactical extensions. > Provided the implementation which does exist will DTRT, w.r.t. the expectations from using the groff >= 1.23 implementation, sure. But if you don't know for sure that any existing implementation mimics groff >= 1.23 behaviour, all bets are off; you surely *do* want to clobber it. I am not in fact so sure about this. Your argument could be extended to every man(7) macro groff supports. I would regard the inlining of the entire macro package (excepting maybe `TH` alone) in the prologue of every man page as too costly. I want groff's man pages to serve as examples for other man page writers to follow, and that would be contrary to the goal, bewildering the novice writer with an avalanche of details. > > groff's man pages all have that logic at the top and bottom that > > takes the body of the page out of compatibility mode, > Sure, but what if that compatibility save, disable, then restore hack doesn't work? This isn't a hypothetical; when multiple man pages were rendered, prior to early in the groff 1.23.0 development cycle, it in fact _never did_ work; see bug #58162. > If the page source is passed through a formatter which doesn't support the 'do' and 'cp' requests, or otherwise support groff extended syntax, then all kinds of output garbage may ensue. That's going to be true even if we don't bother trying to turn on compatibility mode at all (or only do it inside our macro definitions), because non-CSTR #54 syntax is all over the pages anyway, as I noted in comment #3 and comment #4. > > and the pages generally use groff extensions like special characters > > that aren't documented in CSTR #54, often using the \[foo] syntax > > that also wasn't supported by AT&T troff. > In which case, attempting to retain even a modicum of support for legacy formatting engines is likely a forlorn venture, so why bother? A couple or three years ago, Ingo was putting a lot of pressure on me to not "break portability". At the time I didn't have as clear an idea of what formatters were out there actually being used, and how groff's man pages had been falling short of his personal standard for portability for decades--in many cases since James Clark first wrote them. Solaris 10 troff will be end-of-lifed along with the rest of it in about 1 year <https://mandoc.bsd.lv/NEWS>--assuming they stick to their announced plan, so call it a 50/50 chance. Solaris 11 uses groff. I don't think anyone actually uses DWB 3.3 troff as a daily driver. Plan 9 from User Space troff is still developed, but is fairly recalcitrant to innovations, apart from adding the `MR` man(7) macro. This may be due to lack of attention or a low developer head count. So in early 2024 it may be time to look again at updating the backward time horizon for formatters groff expects its man pages to be processed by. > I'm inclined to disagree, only to the extent that any legacy formatter may be confused by them, but maybe I'm just being excessively pedantic. I take the legacy formatter support question seriously insofar as I have any actual evidence that legacy formatters are being used. If we don't concern ourselves with the empirically measurable, then your same argument can be employed to argue against the use of features introduced by Kernighan in ~1981 to device-independent troff, or really to anything subsequent to the first nroff in 1972 or so. As a case in point, and as I have recently documented (i.e., don't bother looking for it in your Manjaro man pages), the `SB` macro was an extension. It was not in Unix Version 7 man(7) in 1979, the first implementation. It wasn't in _any_ man(7) until about 1988, when SunOS 4 introduced it. James Clark swiftly cloned it in groff. As far as I know it was never implemented in any other proprietary troff. But the maintainers of the Korn Shell, which ran on just about every Unix, employed it in their ksh(1) man page early on, never looked back, and if any users complained about its unportability, they were apparently ignored. This should have offended Ingo Schwarze and prompted one of his prophecies of doom; it's just as bad as my/P9US's `MR` because text will be silently omitted if the macro isn't supported. (He has a slightly higher tolerance level for macros that don't take text arguments.) But what has happened in practice? Apparently, no one noticed or cared, and a lot of people assumed it was "standard" when it wasn't. Plenty of people moved away from ksh to something else, but I've never heard a complaint that the unportable man page was the reason. (There were much better ones, from licensing to feature creep. Too much of it got standardized in POSIX as it was, and the hasty adoption of aliases as a standard feature has caused problems literally to this very day. Yes, I mean 24 February 2023. <https://austingroupbugs.net/view.php?id=1630>) > > The idea is to get something that works on Heirloom Doctools troff, > > mandoc, and older versions of groff. This doesn't work perfectly in > > general, but for the MR feature specifically, it does. > Fair enough, provided we're happy to abandon any hope of legacy formatter support otherwise. I think whether we do, or have done this, depends on how one defines "legacy formatter support". Breaking the renderability of man pages on a system that someone does real work on is an anti-goal. Of mine, and I assume of others. Breaking the renderability of man pages on systems that are only run for historical research, I may find a regrettable necessity; I won't break them for _fun_, but if I implement _any_ change to groff (or man(7)) I usually have a reason that is compelling to me because doing so leads to lengthy discussions like this one where I defend my decisions. Breaking the renderability of man pages to systems that are defunct, often unrecoverably so due to lost hardware or software, or to theoretical or future Puritan re-implementations of historical systems, I am indifferent to. I encourage people to write their own text formatters as a couple of Kernighan's books suggested. But a system for deployment to the real world has to deal with real world specimens of input. groff's man pages are as valid in that sense as anyone else's. More than most, I would venture--if you read down mandoc(1)'s NEWS file <https://mandoc.bsd.lv/NEWS>, you will find numerous features, many well down into the weeds of the formatter, that Ingo or Kristaps before him had to implement to sensibly process man pages not written by groff's developers. Put much more simply, I want to avoid _regressing_ portability, which implies a measurable baseline for comparison--real code being used by real people. Objections to new "unportabilities" because they negatively affect unwritten formatters or nonexistent users should not be credited. There may be other reasons to object to a feature, such as poor design or implementation, but deploying unsupported claims of unportability is fallacious argument. I trust you will note that when Alexis demonstrated on the groff list that I had broken portability to real systems <https://lists.gnu.org/archive/html/groff/2023-02/msg00102.html>, rather than arguing with him as I am doing with you, I responded within hours, having reproduced the problem and determined that it was a show-stopper (release-blocker). Within 24 hours I had the change reverted and replaced with one that works. That's the power of empirical measurement and reproducible results. _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?63827> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/
