Emacs Should Adopt HTML as Texinfo Replacement
Dan Davison wrote:
What does this syntax mean? “See Info node `(viper)Top'.”
Is there some way of using it to immediately access the info node referred to?
Lennart Borgman wrote:
M-: (info "(viper) Top")
It'd be much better if emacs adopted HTML as its standard doc format.
It would then just be: ❮http://gnu.org/doc/emacs/viper/top.html❯
in this format, every programer understand what it is.
In (info "(viper)Top")
or (viper)Top
, maybe 0.001% of programers knew what it is.
If we count among all emacs users who used emacs for at least 1 year, the percentage is perhaps 10%.
Personally, i use emacs daily, staying in emacs most of the time when using computer, since 1998, and have been using text terminal based emacs exclusively from 1998 to 2005.
I didn't know what is (info "…")
until 2005 or so thru chatting in freenode's emacs irc.
Adopting HTML as standard doc format is easy to do, in fact mostly just a political gesture. The texinfo util already does export to HTML, and most if not all GNU's doc are already presented in HTML format on GNU's site.
With adoption of HTML, people will naturally cite doc by URL instead of lisp code (info …)
.
This will help understanding and consequently spread emacs.
For example, if in a discussion in some programing forum, someone might mention “look (info xyz) in emacs”.
Vast majority of readers wouldn't understand what that is will simply ignore it.
But if HTML doc is official, then the citing would be ❮http://gnu.org/doc/xyz.html❯, and those who saw this are very likely to click it.
This wouldn't effect emacs much since emacs can and should still use info doc in emacs as a integrated system. But down the road, say in 5 years, emacs will need to deprecate texinfo eventually. The HTML/XHTML/CSS/JavaScript world is literally with few million more users and developers. Their tools, technical power, extensibility, adoption… in every area, are few order of magnitude better than texinfo. In fact, it isn't surprising that modern browser such as Firefox actually render a HTML doc faster than emacs can parse a texinfo file.
By adopting HTML now, it can pave the way for emacs transition to using HTML/XHTML as integrated doc component. For example, currently there's w3m for reading HTML. However, it's some 5 times slower than Firefox, and some 5 times slower than info reading texinfo. However, this can be improved. One could have HTML/XML parser builtin elisp as c code (or borrowing the rendering engine from Firefox), so that reading HTML docs in emacs is acceptably fast as current reading in info.
The integrated nature of info in emacs is really a joy to use, especially programing in elisp. You can lookup any function or keyword in the language so easily, and all cross-referenced by a click-able link. However, if the language is not elisp but Perl, Python, PHP, etc, then it's not so easy because you often have to download and install a info version of their doc (if it exist at all), and depending whether the guy who implemented your lang's mode took the fancy to implement info doc lookup features. (in late 1990s, it's not uncommon to see in a newsgroup or mailing list where someone asking about a info version of a language's documentation so that she can browse it in emacs. Today, HTML and browser is so universal and rooted, the “GNU info” format almost unknown outside of hardcore FSF/GNU community.)
When emacs accepted more HTML docs, it would mean the integrated doc feature automatically apply to all langs, such as Java, Perl, Python, Ruby, PHP, JavaScript, etc since their official doc are all HTML.
Note: Here's some explanation of “M-: (info "(viper) Top")”.
The “M-:” is emacs's notation for keyboard shortcut
Alt+:.
This shortcut invokes the command eval-expression.
So, in order to go to the documentation for “viper” in emacs, a user is told to evaluate the lisp expression (info "(viper) Top")
.
See also:
Emacs M-x key Notation vs Alt+x Notation.
the issue resurfaced by esr.
〔On being web-friendly and why info must die By Eric S Raymond. At https://lists.gnu.org/archive/html/emacs-devel/2014-12/msg00347.html , accessed on 2014-12-07〕
Emacs Modernization
- Emacs Modernization: Simple Changes Emacs Should Adopt
- Why Emacs Keys are Painful
- Emacs: Problems of the Scratch Buffer
- Emacs Modernization: Meta Key Notation
- Emacs Menu Usability Problem
- Emacs Mode Line Problem
- Emacs cua-mode Problems
- Emacs: Inconsistency of Search Features
- Problems of grep in Emacs
- Emacs: Usability Problems of Mode Documentation
- Problems of Emacs Manual
- Emacs Manual Sucks by Examples
- Emacs: kill-buffer Induces Buffer Accumulation
- Emacs Spell Checker Problems
- Emacs: Form Feed ^L Problem
- Emacs: Single Key to Delete Whole Line
- Emacs HTML Mode Sucks
- Emacs Does Not Support Viewing Images Files In Windows
- Emacs Should Adopt HTML as Texinfo Replacement
- Emacs Should Support HTML Mail
- Problems of Emacs's “man” Command
- Emacs Lisp Mode Syntax Coloring Problem
- Emacs AutoHotkey Mode Problems
- Elisp: Syntax Table Sucks
- Emacs: Make elisp-index-search use Current Symbol
- Emacs GNU Texinfo Problems; Invalid HTML
- A Record of Frustration in IT Industry; Disappearing FSF URLs, 2006
- Emacs Manual Node Persistency Issues
- Emacs: dired-do-query-replace-regex Replace ALL (fixed)
- Problems of Emacs Supporting Obsolete Systems
- Elisp: Function to Copy/Delete a Dir Recursively (fixed)
- Thoughts on Common Lisp Scheme Lisp Based Emacs
- Text Editors Popularity and Market Research
- Text Editor's Cursor Movement Behavior (emacs, vi, Notepad++)
- Emacs: Usability Problems of Letter-Case Changing Commands
- Emacs Select Word Command Problem
- Emacs: Search Current Word 🚀
- Emacs fill-paragraph Problem