help-gnu-emacs
[Top][All Lists]
Advanced

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

Re: Emacs documentation. Was My emacs was upgraded and I am a novice aga


From: Stefan Monnier
Subject: Re: Emacs documentation. Was My emacs was upgraded and I am a novice again
Date: Mon, 24 Sep 2007 00:41:25 -0400
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/23.0.50 (gnu/linux)

>> Again, you are confusing format and reader.  The Texinfo format is
>> archaic (but nevertheless quite alive).  The reader is what Emacs
>> offers you.  Nobody has ever proposed a user interface that would be
>> more efficient or convenient than Emacs' current info reader.

> Caveat.  When used to it?

It would be more constructive to tell us which part of the Info reader you
found confusing or lacking.  It used to be a bit tricky to use back when it
didn't support mouse-clicks to follow links, but nowadays I find it to work
largely like web-browsers do, just with better search capabilities and while
using a tiny fraction of the memory (and time) taken by Firefox to display
html documentation.

> My offer is to convert the Emacs documentation into docbook, version 5
> and work with those interested to improve it/bring it up to scratch.

Requirements:
1 - the documentation should be readable on-line from within Emacs.
2 - from a Linux/xterm/PuTTY console as well.
3 - make sure it's as easy to write docbook with Emacs than it is to write
    Texinfo.
4 - have convincing arguments about why docbook is superior.
5 - of course the documentation should also be usable without a screen
    (e.g. emacspeak).
6 - All of the above with tools covered at least by a Free Software license,
    or maybe even with the copyright transferred to the FSF.

There may be a few more, but I think it's a good starting point.
Number 1 means either a robust Docbook->Info translator, or a new elisp
package which renders Docbook (or some other intermediate format generated
from Docbook) directly in Emacs on the fly.  This could potentially use
a bit of C-level coding, linking to xml-processing libraries as long as they
are sufficiently widely supported.
And of course, the features should be a superset, so we need at least a good
indexing system and a full-body search.

> No point if the actual documenters are unwilling to move to XML though.

I don't think it's impossible to make them move, but there's going to be
a lot of resistance: just like in nature you see species which may seem just
"inferior" but they have their niche and they have developed specific
features we just don't understand which makes them better suited in
those niches.


        Stefan


reply via email to

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