[TUHS] Re: Any reason the removal/renaming of read-only registers should be permitted?

[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: Fair, and this occurred to me too. 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]) True, except for the grumbling grognards we're familiar with who fixed their understanding in place many years ago and resist developing it. 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. 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. 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 Already done, and since I didn't add it, probably extant in groff for a long time. $ echo '.nr .l 80n' | nroff troff: <standard input>:1: can't write read-only register This bit of tomfoolery was not overlooked, either: $ echo '.af .l I' | nroff troff: <standard input>:1: can't alter format of read-only register 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