Re: A Roadmap for TexInfo without Info

[Per Bothner]

On 11/26/2016 12:23 AM, Eli Zaretskii wrote:
> > Cc: address@hidden
> > From: Per Bothner <address@hidden>
> > Date: Fri, 25 Nov 2016 07:49:23 -0800
> >
> > On 11/25/2016 01:05 AM, Eli Zaretskii wrote:
> > > Maybe in your argument, but then abandoning Info makes much less sense
> > > to me.  Inventing yet another specialized format and coding yet
> > > another specialized reader means repeating the Info experience over
> > > again, i.e. we didn't learn anything from the current experience.
> >
> > I am proposing plain html (or maybe xhtml), not "another specialized format".
>
> I was replying to this part:
>
> > > > The whole justification of the move to something based on HTML is to
> > > > allow people to use the existing browsers to read the GNU
> > > > documentation.
> > >
> > > No, the justification and my argument goes way beyond that.
>
> "Way beyond that" seems to say that you are not proposing plain HTML
> or XHTML.  If you now say you didn't mean that, I have no problem with
> this part of your proposal.  However, ...

I in turn was responding to "The whole justification ... is to allow people
to use the existing browsers".  My point is there are good reasons to deprecate
info format more generally, including for emacs info mode.

> > I'm proposing focusing on two readers, not "another specialized reader":
> > (1) Generic web browsers, using (optional) JavaScript for info-style navigation.
> > (Of course the html would not *require* JavaScript or CSS.)
> > (2) Emacs, using a melding of eww-mode and info-mode.
>
> Emacs should be out of scope of this discussion, because we all agree
> it will support the new format, and will have no problems doing that.
>
> The important issue is (1).  Making the new format readable with Web
> browsers is the correct direction, IMO, but it needs to solve the few
> basic deficiencies in the current browsers due to which they still
> cannot beat any Info reader.  One of the most important ones is
> index-based search, for example.

I'm not sure what you mean by "index-based search".  That sounds like
searching by making use of a pre-computed index, which is different from
plain searching the actual text, which I though our goal is.

> Your page says specifically that JavaScript is not up to speed for a
> least some of these features.  I know almost nothing about JavaScript,
> but if you are right, then this is a serious problem that needs to be
> resolved.

JavaScript as a language is very capable.  The issue is what to do if
the manual is split - e.g, with separate web pages for each chapter.
How should the JavaScripr search though all the other web pages that
comprise the manual?  That becomes complicated.  One way is to loop through
the other pages by loading each page info an iframe and searching that.
This is slightly complicated (browser security barriers add extra
complication), but doable. It might be slow.

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

https://github.com/timdown/rangy/wiki/Text-Range-Module

People can also use the browser's builtin "find in page" command.

Further advantages of using non-split manuals is that navigation would
be faster; consistent node naming with "hash" URLs; using the browser
scroll bar to navigate.

Note that even if the manual is loaded as a single html page, it is easy
for JavaScript to display it as if it were multiple page, by using
the CSS 'display' property to hide chapters except the current one.  This can
be an option you can instantly turn on or off.

The obvious issue with having a single big page is that it can be slower to
download.  This is rarely a problem if the web page is local, and in an
age of bloated web-pages and fast networks having big "hinfo" pages
is probably acceptable.

So I suggest we focus on single-page manuals, at least initially.

> Perhaps the GNU project should develop plug-ins for the
> popular browsers to solve these problems and provide the necessary
> features.  Or maybe some other solution is possible.

The browser world is moving away from old-fashioned plugins, and adding
more functionality to JavaScript itself.  Asking people to install
a plugin or extension is something we should avoid.

However, if we make switch to using the epub container format
(which is a standard used for ebooks) as a primary distribution format
for GNU documentation, then we might consider extensions.

> But until
> there's a practical solution that can be implemented and installed
> with any modern browser, the proposal to switch from Info to some
> other format is not serious enough for the GNU project to consider,

I disagree.  Note that my proposal is a strict improvement over the
current situation, and does not diminish any existing functionality,
even if search is limited when using a browser.
--
        --Per Bothner
address@hidden   http://per.bothner.com/