[this is mostly philosophical/community/GNU culture stuff] At 2026-05-12T10:39:54-0400, Chet Ramey wrote: > At the end of the day -- and even at the beginning of the next -- > groff is a GNU package, and requires a Texinfo manual. This is a > standard and an expectation.
I know. By the way, Karl Berry told me that Bash went many years
_without_ a Texinfo manual. Is that right? Can you shed light on its
origins?
> You haven't gone as far as some folks, who distribute man pages that
> essentially say "look at the info file," but texinfo has to be there.
Before anybody starts down a road that the factual record will make them
forget, I invite anyone to review the record of my revisions to groff's
Texinfo manual. Please direct my attention to any evidence of disfavor
or lack of care relative to groff's man pages. Thanks.
I think the Info mandate strategy, or more precisely the man page
deprecation strategy, has been more successful at alienating users and
mystifying GNU software to users who are _supposed_ to enjoy the four
freedoms, including those to study and improve the software, than it has
at driving in-migration to Info and GNU Emacs where, we are to believe,
all proper/smart/right-thinking software hackers are.
That attitude is elitist, and, I claim, contrary to the FSF's and the
GNU Project's own objectives of democratizing software development.
Texinfo is fine. I don't hate it. It has its place and serves the
needs of some people. (I wish it had input line continuation syntax as
flexible as *roff's, though.) What I find inappropriate is sticking a
thumb on the scales when selecting a documentation system.
All right-thinking hackers use Emacs to develop software (probably GNU
Emacs, but oh no, not vi).[0]
All right-thinking hackers write manuals in Texinfo.
All right-thinking hackers run GNU/Hurd. (Void where restrictions
apply.)
This sort of heavy-handed favoritism wasn't a good look on Steve Jobs,
and it's not a good look on an organization with as broad a software
delivery mission as the GNU Project.
On the bright side, the demonstrability of that very breadth,[1] and the
promotion and success of high-quality non-Emacs editors like GNU nano
(among many others, including at least one that I suspect will
evangelize at you to compress all your files with lzip) takes much of
the force and sting out of the foregoing quasi-policies.
But I still find the attitudes unworthy and unbecoming, even--or perhaps
especially--when offered in semi-jest.
I confess to some curiosity as to why FSF/GNU sponsored James Clark to
write groff in the first place when, if we retroject the attitudes of
the past 20-25 years to 1990, nobody needed troff typesetting because
TeX and nobody needed man pages because Info.[2] Something about the
umbrella project's ecumenicism has gone understated for many years,
and/or it has some influentially obnoxious exponents.[4]
Maybe someone can shed some light on the history for me.
I admit that working on groff probably wouldn't have appealed to me as
much in the first place if it weren't an underdog in some sense.
Regards,
Branden
[0] I've maintained for years that Vim developers implementing Guile
scripting for it would have been magnificent. If I'd learned Scheme
better when I was younger, I would have been keen to do so myself,
just to make a point that would win me no friends at all.[5] ;-)
[1] https://directory.fsf.org/wiki/GNU
[2] Maybe to spite AT&T and its aggressive rentierism with Documenter's
Workbench, but having accomplished the goal of displacing
proprietary troff (with the help of some savage internal
politics[3]) with about as much success as GCC displaced proprietary
Unix C compilers, why not celebrate groff's success? What accounts
for this bizarre case of buyer's remorse?
[3] https://lists.gnu.org/archive/html/groff/2022-12/msg00097.html
[4] I'm reminded how groff was happily embraced by the Berkeley CSRG
with the Net/2 release and on through 4.4BSD. But, apparently, at
about the time BSDI was spinning up, the knives came out.
"What made the [mdoc] macro package possible was groff. I regret
having had to make the work backward compatible with ditroff. Not
my decision. Would have loved to have rewritten the macros solely
for groff. The package would have been smaller, simpler and
efficient (faster, much faster.)" -- mdoc author Cynthia Livingston,
via Ingo Schwarze
https://lists.gnu.org/archive/html/groff/2025-01/msg00103.html
[5] Like this, which is the worst idea for the worst machine
architecture in the world. I applaud its wickedness and spite.
https://github.com/xoreaxeaxeax/movfuscator
signature.asc
Description: PGP signature
