[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: On being web-friendly and why info must die
From: |
Ivan Shmakov |
Subject: |
Re: On being web-friendly and why info must die |
Date: |
Fri, 05 Dec 2014 14:56:42 +0000 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) |
>>>>> Eric S Raymond <address@hidden> writes:
[…]
> The positioning problem is that info/Texinfo makes us look like a
> steam-powered archaic joke to younger developers. Text-only
> presentation with obtrusive links and a complex command set for a
> viewer that's *not a web browser*? In 2014? Really?
> The capability problem is that the younger developers are objectively
> right to laugh. Because these resources are not rendered to Web,
> they're an informational ghetto with an impoverished internal link
> structure.
I disagree on several points. First of all, there /is/ a
rendition of the Emacs documentation for Web browsers; see
https://www.gnu.org/software/emacs/manual/. If there’s anything
specific to improve to make Emacs documentation more
“Web-friendly” than that, I’d rather be interested in a list.
(And similarly for the majority – if not all – GNU projects I’m
personally interested in. Given the well-known disagreement
between Debian and GNU regarding the use of invariant sections
and cover texts allowed by GNU FDL – /and/ currently used by
several of GNU projects, I happen to use use these Web resources
more than just occasionally.)
Another point is the presence of the ‘Info-index’ command in the
Emacs Info browser. I know of no similar feature to be
generally available for HTML-based browsers, – or HTML-based
documentation, either.
Also, the above made me curious of what exact features of the
HTML presentation are felt missing in Info? (In relation to GNU
documentation, anyway.)
Apart from the above, and given that Emacs now comes with an
HTML browser of its own, I doubt that switching from Info-first
to HTML-first documentation would affect my own workflow
significantly. I’m still concerned over the dependencies (EWW
requires Libxml, while Info seem to be rather stand-alone) and
performance (Info was started on much less powerful machines
than the current “usual” equipment, and presumably will continue
to work there just fine), but I guess these are minor points.
(But if we’re really into the “positioning business” now, I’d
like to refer to this new extensible self-documenting Atom
editor. Which, contrary to Emacs, /does/ work in a Web browser.
I feel we may lose that battle before even starting it.)
> The fact that some of them, like etc/CONTRIBUTE, are plain text with
> no link structure at all certainly doesn't help.
> The EmacsWiki is a valiant stab at fixing part of the problem, but
> its utility is severely damaged by the fact that it can't readily
> link inwards to the stuff carried in the distribution.
To my mind, the biggest problem with EmacsWiki is the one of
obtaining the copyright assignment papers for contributions
deemed good enough to be included into Emacs proper.
Also, to the best of my knowledge, there’re currently no
existing VC backend for EmacsWiki. (There is a crude but
working one for MediaWiki, which is the software behind, say,
Free Software Directory, Wikibooks and Wikipedia, etc.)
[…]
> The policy part of the job will in some ways be more difficult
> because the requirements are harder to define. We need to change the
> way we think about Emacs's documentation; we need to conceive and
> organize it as a single, coherent, richly linked hypertext that
> renders to HTML as its major target.
I’m unsure if I understand the above. Does it mean that instead
of the separate manuals we now have for the Emacs proper, EWW,
Gnus, and what not, we would end up with some kind of a Single
Ultimate Emacs manual? I’m unsure if I’d welcome such a change,
for several reasons.
> This may mean giving up on some features supporting rendering to
> print manuals; I'm not sure yet. If so, it's time to bite that
> bullet.
Somehow, I’ve got an impression that HTML-based typesetting is
the area yet to be really covered by free software. I’d
certainly be interested in the efforts to change that.
[…]
--
FSF associate member #7257 np. Снаружи всех измерений — Гражданская Оборона
- Re: On being web-friendly and why info must die, (continued)
Re: On being web-friendly and why info must die, Alan Mackenzie, 2014/12/05
Re: On being web-friendly and why info must die,
Ivan Shmakov <=
- Re: On being web-friendly and why info must die, Stefan Monnier, 2014/12/05
- Re: On being web-friendly and why info must die, Ivan Shmakov, 2014/12/05
- Re: On being web-friendly and why info must die, Eli Zaretskii, 2014/12/05
- Re: On being web-friendly and why info must die, Lars Magne Ingebrigtsen, 2014/12/05
- Re: On being web-friendly and why info must die, Lennart Borgman, 2014/12/05
- Re: On being web-friendly and why info must die, Eli Zaretskii, 2014/12/06
Re: On being web-friendly and why info must die, David Kastrup, 2014/12/05
Re: On being web-friendly and why info must die, Stefan Monnier, 2014/12/05