* [TUHS] Re: Any reason the removal/renaming of read-only registers should be permitted?
2023-05-03 13:07 [TUHS] Any reason the removal/renaming of read-only registers should be permitted? Douglas McIlroy
@ 2023-05-03 14:29 ` G. Branden Robinson
0 siblings, 0 replies; 2+ messages in thread
From: G. Branden Robinson @ 2023-05-03 14:29 UTC (permalink / raw)
To: Douglas McIlroy; +Cc: TUHS main list, groff
[-- Attachment #1: Type: text/plain, Size: 5087 bytes --]
[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: <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
> (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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread