Hi John, Sorry for the belated response.
At 2025-12-05T23:27:50+1100, John Gardner wrote: > On Thu, 4 Dec 2025 at 03:03, Dave Kemper <[email protected]> wrote: > > > I think some of the reforms you and Erik have been spitballing are > > clear language improvements. My concern is that until such reforms > > are implemented, the current .class method of "or"ing in new flags > > should continue to work (and ideally would continue to work for at > > least one release that does contain the reforms, to give users a > > reasonable migration window). > > > > I apologise for butting into this discussion at random when I haven't > been following the thread closely at all, but catching the part about > reforming the Roff language gave me an idea… > > Why doesn't Groff take a cue from Perl and introduce a `.use [program > version/flavour]` directive that enables authors to opt into newer > features and breaking changes that introduce compatibility/rendering > issues with older documents? The directive need only affect the scope > of the file it's used in (i.e., it's not merely a reheated > compatibility-mode), so macro packages could be "modernised" but > authors using them need not know or care about the newer syntax being > used in files loaded elsewhere. Why not? Overhead in terms of developer effort, I reckon. Perl's had a large development team from its early days. groff does not. > (I'm aware of the innumerable foibles of Roff syntax and how many ways > this suggestion can be shot down, so… fire away, Branden!) I don't think it's a bad idea; it simply may not be a necessary one. I think a "compat-1.24.tmac" approach might suffice. By the earliest point we might need it, for groff 1.25, we _might_ have the string iterator I've been grumbling about for a long time,[1] at which point I expect it would be easy to wrap requests with macros that can minutely reprocess their argument lists, in a manner not too dissimilar from what, as I understand it, ECMAScript does with its fancily named "transpiling" feature that internally rewrites the "modern" dialect into syntax that older interpreters can handle while still delivering the newer language features. If the backward-incompatible changes to a few (mostly esoteric) requests I've made for groff 1.24 without objection should prove to draw angry torches and pitchforks, that could inspire me to urgency in resolving that string iterator issue, as it would seem well-suited to solving the problem. Let's say someone was deeply wedded to historical `cf` request argument interpretation semantics. A "compat-1.23.tmac" file could then do the following. 1. Rename the `cf` request to `compat*cf`. 2. Define a macro `cf` that iterates through its arguments. a. Since it's a macro, the macro call procedure would already have stripped off any leading ". b. If any spaces survive in the first argument, truncate the argument there. c. Invoke `compat*cf` with that (possibly truncated) argument. (Maybe now stick on a leading ", but off the top of my head I think that would be unnecessary.) d. Ignore remaining arguments. I've attempted in my reforms to make the GNU troff language more flexible and regular, not less. As a rule, when you do that, you make the new language capable of emulating the older dialect when the converse might be difficult or impossible. On a somewhat related note, my recent bad experience with bug #67890[2] reminded me of an idea I had a while back but discarded without pitching it to this list. * An `abort` request that just aborts. No arguments, no message. You want a message? Issue a request in the `tm` family first. The traditional `ab` request is non-orthogonal; it both exits (with a failure status in the GNU troff formatter but not on others[3]) and _can_, _optionally_, emit a message. That's a design error. Primitive operations should be primitive, not complex. I didn't fully appreciate how badly this non-orthogonality could bite me until Dave filed that defect report. I want to bite back! :D Regards, Branden [1] https://savannah.gnu.org/bugs/?62264 [2] https://savannah.gnu.org/bugs/?67890 [3] I checked Plan 9 from User Space, DWB 3.3, Heirloom Doctools, and neatroff. On all of these, if you abort, you get exit status zero, making `ab` a pointless synonym of `ex` that doesn't interpret arguments. (neatroff also, uniquely, writes an entire "trout" document even when given no other input.)
signature.asc
Description: PGP signature
