[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: 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. Снаружи всех измерений — Гражданская Оборона

reply via email to

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