[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 19:10:35 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

>>>>> Stefan Monnier <address@hidden> writes:

 >> 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.)

 > The main issue with the Info format is that it's not designed to be
 > parsed.

        ACK, thanks.  I guess I should’ve really figured this simple
        thing out myself; and the rest becomes pretty obvious, indeed.

 > Even the tiny bit of parsing that's expected (i. e. find menu entries
 > and hyperlinks) is not very well designed (e. g. restrictions on the
 > kind of characters that appear in a menu entry).

 > So we can present it "as is" in plain-text as was done back in
 > Emacs-19, but it's difficult to prettify the various elements in a
 > reliable way.  We do try to do it (e. g. hide some of the verbosity
 > of the hyperlink's syntax,

        Curiously, this particular Info mode behavior was mentioned on
        IRC not so long ago (2014-10-28), where a participant claimed it
        was an unwanted feature with no documented means to disable
        (sans redefining Info-fontify-node.)  Which then prompted me to
        dig somewhat into the history.

        As I was able to find, while this feature was already available
        in 2004, the use of (setq Info-fontify-maximum-menu-size nil) to
        disable it was indeed only documented 2007-02-10.

        … The point is, I guess, that there’re those who still follow
        the ways of Emacs 19-or-so, and are just happy with that.

        Forcing all the Emacs years-long users to switch to EWW for
        reading Emacs’ own documentation would be (irrespective of how
        do I like EWW and HTML myself) a sure fail.

 > use different fonts for different elements), but this is inevitably
 > very limited because it's all done heuristically: e. g. the Info
 > format does not tell us which part of the text is "text" and which
 > part of the text is "quoted code", so we can't refill (which would
 > sometimes be needed after hiding the hyperlink syntax) and we can't
 > use proportional fonts for the text part since that would mess up the
 > code example parts.

        Somewhat tangential to the discussion, investigating possible
        means to make shr.el use (setq truncate-lines nil word-wrap t)
        for the text at the top of the “rendering tree” – instead of
        plain filling – is on my “to do” list.  (The current
        implementation effectively assumes a fixed-width font; see,
        e. g., shr-width.)

FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A

reply via email to

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