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 [email protected] http://per.bothner.com/
