Hi Per, Per Bothner <p...@bothner.com> 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’.
