[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: On being web-friendly and why info must die

From: David Kastrup
Subject: Re: On being web-friendly and why info must die
Date: Sat, 06 Dec 2014 10:09:09 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

Christopher Allan Webber <address@hidden> writes:

> Eric S. Raymond writes:
>> rST, Sphinx and asciidoc don't have that problem.  Among those, I think
>> asciidoc wins because it's achieved more desigh wins in high-profile
>> projects.
> The number of high profile projects on https://readthedocs.org/ using
> sphinx these days is pretty crazy high... probably one reason Sphinx has
> gotten such a large amount of development.
> At any rate, I think if you're going to do one of these, there's still
> the advantage that Sphinx can still generate texinfo, so that doesn't
> have to be lost.

An output format is not the same as an input format.  We can generate
PostScript from our Texinfo documentation, but that does not mean that
this is of any use to people wanting to write our documentation in
PostScript.  The only usefulness is for a one-time conversion after
which you are going to continue maintenance in PostScript.

So Sphinx being able to write Texinfo is not useful for switching Emacs'
documentation over to Sphinx or maintaining it in Sphinx.

I also have a very hard time buying the idea that if Emacs was
documented in Sphinx or whatever the newfangled language of the day is,
we would suddenly gain a large influx of competent documentation

Because, guess what, the main impediment to writing high-quality
documentation for Emacs is not that it needs people willing to learn the
two dozen commands relevant for writing Texinfo in one of the
well-supported Emacs modes for it.

The main impediment is that it needs people willing to learn the ten
thousands of commands constituting Emacs.  And if the hurdle of Texinfo
is insurmountable for them, Emacs will be off the charts.

David Kastrup

reply via email to

[Prev in Thread] Current Thread [Next in Thread]