Re: A Roadmap for TexInfo without Info

[Eli Zaretskii]

> Cc: address@hidden
> From: Per Bothner <address@hidden>
> Date: Sat, 26 Nov 2016 08:59:12 -0800
> 
> >>> 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.

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.

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

The 'i' command in the Info reader.  It has 2 related functions, both
of which are extremely useful when using a manual as a reference (as
opposed to reading it or its large parts in their entirety):

  . "i SUBJECT RET" lands you in the first node that discusses SUBJECT
  . "i SOMETHING TAB" pops up a list of completion candidates, which
    tells you what subject starting with SOMETHING are discussed by the
    manual

Any Info browser that doesn't have these features is not capable
enough to be a replacement for current Info readers.

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

Plain searching through the entire manual is also a very important
feature, but it is only used when the index-based search failed,
because it is much less efficient.  It is less efficient because the
index was created by a human who deliberately indexed certain subjects
knowing that readers will look for them, and that is different from
searching the text for random words.  In particular, it is quite
possible that some subjects that are in the index will not be found
verbatim anywhere else in the manual.

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

It must work, and it must be reasonably fast.  Otherwise, looking up
something in a manual becomes an annoyance.

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

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

That probably doesn't support regular expressions, while Info readers
do.

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

It's only worth focusing on that if the same technique can be extended
to support split manuals.

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

Maybe so, but if no other solution is at hand, I see nothing wrong
with providing a plug-in or add-on.  All of my browsers have them,
e.g. to display PDF files, so I'm not sure what does "is moving away"
mean in practice.

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

Your proposal is just a proposal.  A proposal cannot supplant an
existing program.  We need to have the proposed ideas implemented, and
implemented well, using modern browsers as the target platforms.  Only
then we can toss the stand-alone Info reader.  Until then, we can
discuss as long as we want, but nothing will really change.