[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Per Bothner
Subject: Re: Any interest in using HTML for locally-installed Texinfo documentation?
Date: Tue, 2 Apr 2019 08:31:06 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1

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

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 .

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]