[adding groff to CC list since this is a reply to a message I posted there] Hi Doug, Thank you for your considered response. At 2023-05-03T09:07:03-0400, Douglas McIlroy wrote: > I think Clark was justified in deviating from Ossanna. > > The prime rationale for allowing removal of read-only registers is > uniformity--a powerful argument. Fair, and this occurred to me too. > It simplifies documentation This, I would quibble with. I feel morally compelled to document this as one of many differences from AT&T troff. On the bright side, in groff documentation, those considerations are for the most part confined to dedicated sections that the newcomer or other user without mastery of the AT&T troff dialect easily can pass over. (And a good thing, as those portions of the documentation have grown measurably since I started contributing, mainly to document differences that have been in place for many years.[1]) > and relieves a burden on users' understanding. True, except for the grumbling grognards we're familiar with who fixed their understanding in place many years ago and resist developing it. > It probably simplifies the code, too. Assuredly that. In reviewing the class hierarchy for registers in groff, I see that I would at the very least need to add a virtual member function `locked` to an abstract base class. Or possibly reorganize the class hierarchy to add a new layer. I had not decided upon a course yet, because I found some logically prior cleanups that I wanted to do first. > This kind of special-casing is AI in the service of some perception > that "no one would want to do that.". If "that" is the clear meaning > of some specified action, then so be it. We are not dealing with > physical hazards here. I would agree that if someone can screw up the formatter's state by deleting a read-only register, then that bit of state was improperly shielded from the *roff language interface in the first place. And to be fair, I haven't yet found any evidence of such. To take an easily understood example, you can blow macro packages and documents to holy hell by removing the `.l` register if they blithely assume they can get the truth from it, but the formatter still knows what the line length is. $ cat EXPERIMENTS/remove-.l-register.roff .de XX foo bar baz qux .br .. .ll 8n .tm .l=\n(.l .XX .rr .l .tm .l=\n(.l .XX .ll +2n .XX .ll -2n .XX .pl \n(nlu $ cat out foo bar baz qux foo bar baz qux foo bar baz qux foo bar baz qux $ cat err .l=192 .l=troff: backtrace: file 'EXPERIMENTS/remove-.l-register.roff':9 troff:EXPERIMENTS/remove-.l-register.roff:9: warning: register '.l' not defined 0 DWB 3.3 nroff stdout is the same. > > even if they don't screw up the formatter internally, > > they will become unrecoverably useless for documents > > and macro packages, > > The same argument could be made about \applying .rm to any standard > request, and I would disagree for the same reason as above. (A > disappointing experimental discovery in this regard: .de seems to be > immune to removal.) I have good news for you! Removing `de` seems to work just fine for me in groff 1.22.4 and Git. $ nl EXPERIMENTS/remove-de-request.roff 1 .de A 2 foo 3 .. 4 .rm de 5 .de B 6 bar 7 .. 8 .B 9 .pl \n(nlu $ nroff -ww EXPERIMENTS/remove-de-request.roff troff: EXPERIMENTS/remove-de-request.roff:5: warning: macro 'de' not defined troff: EXPERIMENTS/remove-de-request.roff:7: warning: macro '.' not defined troff: EXPERIMENTS/remove-de-request.roff:8: warning: macro 'B' not defined bar > A change that I *would* welcome is warning about writing into a > read-only register. Already done, and since I didn't add it, probably extant in groff for a long time. $ echo '.nr .l 80n' | nroff troff: :1: can't write read-only register This bit of tomfoolery was not overlooked, either: $ echo '.af .l I' | nroff troff: :1: can't alter format of read-only register > (Also make .rm work on .de--a near reversal of the original proposal.) groff might conform to your expectations better than you thought it did. I observe that no one seems to have ever complained about, or even noted, this GNU troff difference from AT&T. I do think groff's documentation could benefit from a warning to the callow that destruction of predefined requests, registers, and (one) string is an irreversible process. I will shelve this reactionary idea for the indefinite future, then. As an anti-reactionary by temperament, that suits me down to the ground. ;) Regards, Branden [1] The exception being the change, forthcoming in groff 1.23.0,[2] to to the interpretation of `\s11`, `\s24`, `\s36`, and similar. https://git.savannah.gnu.org/cgit/groff.git/tree/NEWS?h=1.23.0.rc4#n35 [2] Now at release candidate 4! Try it today! https://lists.gnu.org/archive/html/groff/2023-04/msg00135.html