From mboxrd@z Thu Jan 1 00:00:00 1970 From: Per Bothner Subject: Re: Any interest in using HTML for locally-installed Texinfo documentation? Date: Tue, 2 Apr 2019 08:31:06 -0700 Message-ID: References: <87a7h8u4r4.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Return-path: In-Reply-To: <87a7h8u4r4.fsf@gnu.org> Content-Language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-texinfo-bounces+gnu-bug-texinfo2=m.gmane.org@gnu.org Sender: "bug-texinfo" To: =?UTF-8?Q?Ludovic_Court=c3=a8s?= , Gavin Smith Cc: guix-devel@gnu.org, Texinfo List-Id: guix-devel.gnu.org 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 per@bothner.com http://per.bothner.com/