bug-texinfo
[Top][All Lists]
Advanced

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

Re: A Roadmap for TexInfo without Info


From: Per Bothner
Subject: Re: A Roadmap for TexInfo without Info
Date: Sat, 26 Nov 2016 23:42:19 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0



On 11/26/2016 07:43 PM, Eli Zaretskii wrote:

As an experiment I tried:
   makeinfo --html --no-split emacs.texi -o /tmp/emacs.html

Loading file:/tmp/emacs.html (4.2MB) was close to instantaneous in Chrome, but
took about 2 seconds in Firefox.  Either was pretty zippy navigating or doing
a plain text search.  A search implemented in JavaScript might be a
different matter, though.

We were talking about searching through a manual split into multiple
files.  You said that might be slow, so I said it shouldn't be too
slow.  I don't see how your experiment is relevant.

I just wanted to get a quick feel for how it feel to browse a large non-split
manual, as a single web page, since navigating and searching non-split manuals
would be both faster and simpler.

First impression is that using non-split web-pages could be tolerable,
but with start-up slower time than we'd like.  So it's probably not the way to 
go.

I had an idea do a hybrid: Conceptually (and to the user) each manual
is a single web page. However, it consists of a sequence of parts:
Each part is sourced by a separate html page, loaded lazily into its own iframe.
Each iframe is loaded lazily, the first time it is scrolled into view
or the first time you do a full-text search.  (Actually, there is no iframe
until it is needed - it is just a blank block.)

The URLs in this model would have the same hash-based form as
in a non-split manual - e.g. "emacs.html#Buffers".  Following an
internal link never re-loads the whole page.  Instead it updates
the browser's location bar, and scrolls the corresponding element into view,
if necessary first creating and loading the containing iframe.

Somewhat complicated (and beyond what I have done), but probably fairly
efficient and not excessively difficult to implement.

Btw, Info readers also support compressed manuals, and many projects
compress Info files by default.  So that's also something to consider
implementing in the browsers.

Web pages are commonly compressed when sent over http.  However, neither
Firefox or Chrome were able to open file:/tmp/emacs.html.gz.

If we don't mind using a single web page for a manual (i.e. use --no-split)
then the search is much easier.

We do mind, I think.  The Web is full of manuals split by node or by
chapter, so they must be supported.

Huh?  We only need to support whatever we (makeinfo) generates, not
whatever the web is full of ...

Those manuals were generated by makeinfo, so there's no contradiction.

My point is: The only manuals on which we can provide an info-like UI
are those that are re-generated freshly by a new makeinfo - at which
point we can recommend/require that --no-split be used.
(I realize there are problems with that, including that old links
may no longer work, and old Makefiles might have to be changed.)
--
        --Per Bothner
address@hidden   http://per.bothner.com/



reply via email to

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