From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?utf-8?Q?Ludovic_Court=C3=A8s?= Subject: Re: Any interest in using HTML for locally-installed Texinfo documentation? Date: Wed, 03 Apr 2019 23:11:36 +0200 Message-ID: <87ef6ipzef.fsf@gnu.org> References: <87a7h8u4r4.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: (Per Bothner's message of "Tue, 2 Apr 2019 08:31:06 -0700") 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: Per Bothner Cc: guix-devel@gnu.org, Texinfo List-Id: guix-devel.gnu.org Hi Per, Per Bothner skribis: > On 4/2/19 2:37 AM, Ludovic Court=C3=A8s wrote: >> Yet I=E2=80=99m not completely sold to the everything in the browser app= roach, >> and everything in JavaScript. In an ideal world (for me), we=E2=80=99d = 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=E2=80=99s what I meant. :-) I find things like DOMTerm very impressive, and it=E2=80=99s 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=E2=80=99re talking about code bases orders of magnitudes bigg= er 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=E2=80=99s an experiment that Andy Wingo did about 15 years (?!) ago. Andy wrote the Texinfo parser that=E2=80=99s 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 . Unfortunately the screenshot has disappeared.) That said, it surely is quite a bit of work, but I think it=E2=80=99s an op= tion we could consider. >> When talking about ease of access, we can=E2=80=99t ignore keyword searc= hes. >> How would you do =E2=80=98info -k=E2=80=99? How would you even simply p= oint 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 =E2=80=98hxmlxref.cnf=E2=80=99 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 l= ogic > 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=E2=80=99s a side issue, which is that HTML documentation tends to = take >> quite a lot of space, but we=E2=80=99ll see whether that=E2=80=99s a pro= blem. > > 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 =E2=80=98Content-Encoding: gzip=E2=80=99. Thanks, Ludo=E2=80=99.