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

[Per Bothner]

On 4/2/19 2:37 AM, Ludovic Courtès wrote:
> Yet I’m not completely sold to the everything in the browser approach,
> and everything in JavaScript.  In an ideal world (for me), we’d rather
> provide a local documentation viewer

 I don't think we're aiming for "everything in the browser".  A closer
approximation  is "everything using html+javascript".  I.e. using html
as the file type and JavaScript as the UI implementation language.
That does not require a traditional desktop browser: You can write
a nice desktop application using Electron, or Qt (QtWebEngine),
or Gtk (WebKitGTK), or Java (JavaFX/WebView).  You use one of these
toolkits to create a top-level window, with whatever "chrome" (window
frame, menus etc), but most of UI would be in JavaScript.  (I do have
a nice pure-JavaScript implementation of menus (menubar and popup), BTW.)

I have a lot of experience doing something similar for the DomTerm terminal
emulator (https://domterm.org): Display management, escape sequence
parsing, keyboard command processing are all handled by JavasScript.
This JavaScript can run in a regular browser (Firefox and Chrome and
been tested most) or using an Electron or Qt wrapper.  It works very
well - using Electron or Qt it looks and acts just like a regular terminal
emulator.  You start it up with a 'domterm' command, which depending on the
command-line switches forks a pty and creates an Electron/Qt/browser window.

> that renders Texinfo directly.

That's a lot of work, and I see little benefit to it.

> When talking about ease of access, we can’t ignore keyword searches.
> How would you do ‘info -k’?  How would you even simply point your
> browser to a specific manual?  What about inter-manual cross-references?

You can still have an 'info' command, which would parse the command-line,
find the appropriate html file, and then start up an Electron/Qt/browser
window.

If running under DomTerm or similar, the 'info' command can even re-use the
existing terminal window.  See the output from 'domterm help' in the
top-right pane of the first screenshot at http://domterm.org/index.html .

> Would we need a mechanism similar to ‘hxmlxref.cnf’ but that would
> browse local manuals?  What would be the recommended solution for Emacs
> and console users?

I think the best approach for Emacs is a hybrid of eww and info modes:
Instead of reading an info file, it would read an html file, which would
be displayed using eww.  However, the keybindings and search/navigation logic
would be based on that of info mode.

On a plain terminal, info could either create a fresh window, or it
could delegate to 'emacs -nw'.

> There’s a side issue, which is that HTML documentation tends to take
> quite a lot of space, but we’ll see whether that’s a problem.

It does require some more space, but it should compress fairly well.
What I do for the Kawa manual is generate an 'epub' archive, which is
basically a zip archive, with compression.  It is fairly simple for a
web server to extract a zip member and send it to a browser directly
as a gzip-compressed file, without actually decompressing the file
(until it gets to the browser).  I contributed support for this to
https://libwebsockets.org/, which is a compact C-language http server.
DomTerm uses this to "serve" the JavaScript files to the browser,
and a revamped 'info' program could do the same.
--
        --Per Bothner
address@hidden   http://per.bothner.com/