From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,MAILING_LIST_MULTI, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 22079 invoked from network); 3 May 2023 14:29:26 -0000 Received: from minnie.tuhs.org (2600:3c01:e000:146::1) by inbox.vuxu.org with ESMTPUTF8; 3 May 2023 14:29:26 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 2FF36414CD; Thu, 4 May 2023 00:29:22 +1000 (AEST) Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) by minnie.tuhs.org (Postfix) with ESMTPS id 6C646414BE for ; Thu, 4 May 2023 00:29:16 +1000 (AEST) Received: by mail-ot1-x32b.google.com with SMTP id 46e09a7af769-6a5f8e1f6d1so2094898a34.0 for ; Wed, 03 May 2023 07:29:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683124155; x=1685716155; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=N3v4KpDwfrr3PwOKe8i+adSLpebRo5NfEpEdISKybGI=; b=PXiBtEtZxOTqSEvFSYJgCN0lOqT4pGKRScvScH77T4yPiCq0G7eYDKd9SOlgpWlDyO 7o3aayIwyrtuOuZ7Mwt26rel9D+9LFALzVDAW8kS0IPNggr7YbfEYyYaP2urXtGB+gEU Rr5Zt8hVXwYThjMjTIaV45rCWCFZcLqmi4/2yfKSBZTlllOl+XkJ+z2rEgPaix4gDv4o xi7XpfCr4vBBIpcWHSCMux4vWomijUJc3vCvXIeaomqdyrfxPVaZgnC7JVmWDOYcmNCY OmqJoB1139kEtlIIDnZ+Ofmo2YY7TaWxpLuxN3vMOttEn0RPmqak+1Uj/FpAKigBQPER WpHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683124155; x=1685716155; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=N3v4KpDwfrr3PwOKe8i+adSLpebRo5NfEpEdISKybGI=; b=BaRyRCgARZOniXlcXZqP+ASALgCulBHT69i/lwvqk096d1W5CE+0KVVcfF8+XbKjNE S7mDsx2dTpYD1zM7MopQi8GkgG43yvlAXOuUN+luwTR/BDJOquNKw7gjFifeyD+mBCuY xGR2yL26aX+8bhwZY7Ol9f5H8ubd0wGUrpyHC63lO/OxhnmXo0CxPJoql3IGmHiJyBF7 I+zVaYI6khJALwpBqWHbLvWsRMKeOymlRY35FhGa8Y4XKkR2+6e3R3Au1LCt8sr8a1I0 su7vJe/Nj47nP/pEipYSyIdrxV1Iq8syB5kSCn1XcJia+Jjjha1LQAojmd8jg1jS0BfJ SGhw== X-Gm-Message-State: AC+VfDyDZm7LbpBmzCLgiFdjGxLe5Uoh9eAJZRsDte0a627J+BU6s3uu H1A2OxBa6gJk6ZoL862iHx0E2KWxvDI= X-Google-Smtp-Source: ACHHUZ58XdxTdCMprNr59bTOVhQddViIsDQN909rBxsOcZ0kg9RyA3xEqfvq8Y31N4F1552NysiN8A== X-Received: by 2002:a05:6808:6349:b0:387:3b8:f879 with SMTP id eb9-20020a056808634900b0038703b8f879mr86056oib.56.1683124155338; Wed, 03 May 2023 07:29:15 -0700 (PDT) Received: from illithid (ip68-12-97-90.ok.ok.cox.net. [68.12.97.90]) by smtp.gmail.com with ESMTPSA id q15-20020a9d664f000000b006a3df644d31sm632543otm.37.2023.05.03.07.29.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 May 2023 07:29:14 -0700 (PDT) Date: Wed, 3 May 2023 09:29:13 -0500 From: "G. Branden Robinson" To: Douglas McIlroy Message-ID: <20230503142913.bmgfic4yeafvqebb@illithid> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7n65xcp5sltqei7m" Content-Disposition: inline In-Reply-To: Message-ID-Hash: 2STONMABINVUZ3H5SRQOM5Z77UYEOFD7 X-Message-ID-Hash: 2STONMABINVUZ3H5SRQOM5Z77UYEOFD7 X-MailFrom: g.branden.robinson@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: TUHS main list , groff@gnu.org X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: Any reason the removal/renaming of read-only registers should be permitted? List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --7n65xcp5sltqei7m Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [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. >=20 > 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 =2Ede XX foo bar baz qux =2Ebr =2E. =2Ell 8n =2Etm .l=3D\n(.l =2EXX =2Err .l =2Etm .l=3D\n(.l =2EXX =2Ell +2n =2EXX =2Ell -2n =2EXX =2Epl \n(nlu $ cat out foo bar baz qux foo bar baz qux foo bar baz qux foo bar baz qux $ cat err =2El=3D192 =2El=3Dtroff: backtrace: file 'EXPERIMENTS/remove-.l-register.roff':9 troff:EXPERIMENTS/remove-.l-register.roff:9: warning: register '.l' not def= ined 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, >=20 > 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=3D1.23.0.rc4#n35 [2] Now at release candidate 4! Try it today! https://lists.gnu.org/archive/html/groff/2023-04/msg00135.html --7n65xcp5sltqei7m Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEh3PWHWjjDgcrENwa0Z6cfXEmbc4FAmRSb7IACgkQ0Z6cfXEm bc4ncA//a9ooSGOZ1T9K/puKQ3hn1v4v25Nm94YVAHtOnspU5fgcJNKWORSe75VV Qiyspv5Oh6H4uxTWBN/eEPEmA33QR6UmE9CXimBHy/6yNDt+N4E1AAr5OVZSbYce jJow1VmelqI+HyRm9hp0TTFNW3IUjRvURFfyz+UtYcir6Y9ieY3dAh8WokG3/51N CuT6B56GtjVAmxVWgvUItD7sytTJTeGV808hl8mlf173LLASOQ09xpn2+eFNdYnP BCtBhxTDXxZ9FwNXPCkuAS06I8vDyIUZt53tfYOieX0p0Oqx98PqWQpTXeAEQqhC Wppta4HdPfvAG1ueAJC0RyynrjHNJ/d2XufOmJV+eZvMQ6M7MWuIS3wx8yBeWjwi Wb+UHplmssE/6H6HeOy9rrNkbTjPV92KyFiqDKf+PrHzXEonDEIPfxuMH4AzBjbf 3ez8uHHdguMuydSiVpA08QuYEvOKxBHE93zu8UDLc9nl2NfrNAiV/UaNUXOTTYTe clRe6RFlnnQU+4VovUM4Z0TtAq1NzvKbbZAnSzrYPZBvNuDwAbMbW3aVAe3MHhao aw0FUnr0dqpSHc+koa73fsvGF1Xpho/ICWC6TsqAGwWc7PMd97bLxzWsW85h25l4 kw4trRRF45bcv2aDdnJdV3xuJ576R0vEm3hfkVdDnr/BqTHmFZQ= =78Rm -----END PGP SIGNATURE----- --7n65xcp5sltqei7m--