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

[Ludovic Courtès]

Hi Per,

Per Bothner <address@hidden> skribis:

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

Yeah, that’s what I meant.  :-)

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

>> that renders Texinfo directly.
>
> That's a lot of work, and I see little benefit to it.

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.

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

Sounds like a plan.

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

Yes.

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

A simpler solution might be to use ‘Content-Encoding: gzip’.

Thanks,
Ludo’.