On deprecation (was: .TQ to replace .PD 0)

[G. Branden Robinson]

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