Ralph, At 2022-05-23T10:22:58+0100, Ralph Corderoy wrote:
I find your post to be fallacious. > It seems pointless for GNU Groff to attempt to deprecate .PD when it > is only one of the man-page formatters and has no control over the > many existing man pages. Let's plug different nouns from our field into this sentence and see if it continues to make sense. "It seems pointless for WG14 to attempt to deprecate C language trigraphs when it produces no compiler of its own and has no control over the corpus of C programs." So, that would be a "no".[0] groff can deprecate what it chooses; the wisdom of doing so is a question that must be debated on grounds other than those you have chosen. > Even if GNU adherents strike out its use within their reach, it must > still be supported. Yes. Who has proposed dropping support for it? Please cite your source. `AT` and `UC` are deprecated by groff man(7) as well, and have been for over 19 years. https://git.savannah.gnu.org/cgit/groff.git/commit/?id=4857b794573534c61283d287939dc9f297aa5897 Yet no one, as far as I have seen, has proposed dropping support for these macros: they are useful, as the current text of groff_man(7) says[1], for rendering historical pages. The reason these macros are termed "deprecated" is that they are disfavored from a design perspective for production of new man(7) documents. Deprecation is not a threat to withdraw support: where that is contemplated, groff documentation strives to warn about it, as with "nroff -h" (and even that warning is hedged with the phrase "may eventually")[2]. You curate a lot of documentation on your site, troff.org; it is a shame that you seem not to devote even a fraction of that attention to groff despite your frequent participation on our mailing list. > To deprecate it just introduces confusion No, it doesn't "just" do that. It reduces the number of macros that a man(7) document author needs to know to write an effective page. Please point out how, precisely, the current wording of groff_man(7) is unclear or misleading. I have labored long over that page and would welcome the opportunity to further prevent misconceptions. > to users in the same way as the revisionism which is renaming central > core concepts from their familiar, long-held, names. Which "central core concepts" are these? Because you are vague, I must assume you are referring to the term used to label the `\&` escape sequence, which was discussed earlier this month on this list[3]. But maybe not; perhaps you are inviting the reader to speculatively substitute something they think of as a core concept in typesetting, like filling or breaking, and thus tempting them to assume that groff documentation has been rewritten to use an insular jargon, like Lojban grammar manuals. But that is not the case. Because I do much work on groff documentation, I can attest that it attempts to hew to generally accepted terms and denotations, with exceptions arising only where ambiguity threatens, or when explaining such terms to the uninitiated. (The word "break", for instance, has many meanings.) Since you have so often used Strunk & White as a bludgeon against my writing, I must furthermore ask you if there are any "central" concepts that are not also "core". Are both words necessary here? Or are you simply inflating your rhetoric, as with your use of the term "revisionism", larded with Cold War connotations[4]? > There are many things which would be done differently today than forty > or fifty years ago, but GNU Groff's role in being software compatible > with the Unix version should not be the playground in which to toy > with these changes. New macros packages allow much more freedom. And > wouldn't it be great to see a new text formatter in a modern language > like Go try all sorts of experiments whilst still tipping its hat > towards troff in its basic line-oriented, low noise, syntax? You take a such a reverential attitude toward historical implementations and their documentation--down to the last jot and erratum--that I would challenge you to enumerate several of these, take your own advice, and go about developing them as an exercise. I show my work multiple times a week to the groff-commit and bug-groff lists. Where is yours? Your persistent derision not only of my contributions to groff but those of others like Werner (see above) and Ingo[5] is corrosive to the collegial attitude and good cheer that should characterize any software project, volunteer or professional. Without a friendly environment for contributors, groff is at risk of stagnation. But it's an ill wind that blows no one any good--if it were to do so, an update of your web site would appear less urgent[6]. --Branden [0] https://www.open-std.org/JTC1/sc22/wg14/www/docs/n2940.pdf [1] https://git.savannah.gnu.org/cgit/groff.git/tree/tmac/groff_man.7.man.in#n2783 [2] https://git.savannah.gnu.org/cgit/groff.git/tree/NEWS#n80 [3] https://lists.gnu.org/archive/html/groff/2022-05/msg00010.html [4] https://en.wikipedia.org/wiki/Revisionism_(Marxism) [5] https://lists.gnu.org/archive/html/groff/2022-05/msg00005.html [6] https://lists.gnu.org/archive/html/groff/2022-03/msg00107.html https://lists.gnu.org/archive/html/groff/2022-03/msg00108.html
signature.asc
Description: PGP signature
