Re: A Roadmap for TexInfo without Info

[Eli Zaretskii]

> Cc: address@hidden
> From: Per Bothner <address@hidden>
> Date: Sat, 26 Nov 2016 12:37:03 -0800
> 
> On 11/26/2016 09:43 AM, Eli Zaretskii wrote:
> >> 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.
> >
> > IMO, it only makes sense to deprecate the Info format if we have a
> > capable replacement for it.  Otherwise, the discussion about
> > deprecating it is academic, because no one will agree to throw away a
> > very useful functionality without having a replacement that is
> > equivalently capable.
> 
> You're being a bit inconsistent here.  You're talking about "very useful
> functionality" which currently only exists in emacs info mode and the
> info program - and you earlier stated emacs info is not a problem
> because we can do anything we need even if we change the format.
> 
> What you appear to want is the full functionality of emacs info mode but
> using a generic browser.

No, I want the full functionality of the stand-alone Info reader.
There's no inconsistency.  (Btw, there's very little that the Emacs
Info reader can do that the stand-alone reader cannot, but that's
beside the point.)

> This is not something we have, so there is nothing to "throw away".

We definitely do have the stand-alone reader.

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

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.

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