Re: Any interest in using HTML for locally-installed Texinfo documentation?

[Gavin Smith]

On Wed, Apr 03, 2019 at 11:11:36PM +0200, Ludovic Courtès wrote:
> I find things like DOMTerm very impressive, and it’s true that
> HTML/JS/CSS nowadays constitute an unequaled UI framework (to the point
> that GNOME Shell is also written in JS + CSS.)
> 
> That would be a good argument in favor of doing things this way.  Yet, I
> have to say that this is not a direction that I like, technically and
> otherwise (we’re talking about code bases orders of magnitudes bigger
> than all of Texinfo including info-stnd, and code bases under the
> control of a couple of companies.)

We need something that can render text and has hyperlinks.  When 
the user clicks a hyperlink, the program should have control over what 
happens.  It doesn't sound like a very complicated problem.  

Maybe there is a lightweight solution that doesn't require embedding a 
full web browser in the program.  For example, in Qt there is the QLabel 
widget which appears to support links in text: 
https://doc.qt.io/qt-5/qlabel.html#signals

It may be possible to change the embedded web browser to a different 
one if a company controlling it takes it in a bad direction.

Ideally, we'd avoid tying a graphical help browser into large frameworks 
like Chromium.  However, I think that an embedded browser (as in 
DomTerm) is a good place to start, reusing the existing JavaScript code.
Maybe simpler solutions could be explored later.

I've been trying to learn about Qt and it certainly is quite complex 
(taking many hours to compile some of its development tools).

> I was mentioning this because it’s an experiment that Andy Wingo did
> about 15 years (?!) ago.  Andy wrote the Texinfo parser that’s now part
> of Guile, and then had a Guile-GTK program that used a tree widget to
> show the contents, had clickable links, text would reflow, etc.  (See
> <https://wingolog.org/archives/2004/07/25/literate-programming-with-guile-lib>.
> Unfortunately the screenshot has disappeared.)
> 
> That said, it surely is quite a bit of work, but I think it’s an option
> we could consider.

This is an interesting idea.  How far developed was the program?  Is it 
still extant?  texi2any has its own Texinfo parser, written in Perl and 
C.