From: "Ludovic Courtès" <ludo@gnu.org>
To: Per Bothner <per@bothner.com>
Cc: guix-devel@gnu.org, Texinfo <bug-texinfo@gnu.org>
Subject: Re: Any interest in using HTML for locally-installed Texinfo documentation?
Date: Wed, 03 Apr 2019 23:11:36 +0200 [thread overview]
Message-ID: <87ef6ipzef.fsf@gnu.org> (raw)
In-Reply-To: <cbdc5044-553c-5934-251f-f015acd6b504@bothner.com> (Per Bothner's message of "Tue, 2 Apr 2019 08:31:06 -0700")
Hi Per,
Per Bothner <per@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’.
next prev parent reply other threads:[~2019-04-03 21:11 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-01 12:55 Any interest in using HTML for locally-installed Texinfo documentation? Gavin Smith
2019-04-01 14:01 ` sirgazil
2019-04-02 9:37 ` Ludovic Courtès
2019-04-02 15:02 ` Gavin Smith
2019-04-02 16:46 ` Per Bothner
2019-04-07 16:28 ` Gavin Smith
2019-04-08 15:12 ` Ludovic Courtès
2019-04-08 15:39 ` Pierre Neidhardt
2019-04-08 23:46 ` Gavin Smith
2019-04-09 6:25 ` Eli Zaretskii
2019-04-13 16:21 ` Gavin Smith
2019-04-14 19:25 ` Pronaip
2019-10-15 19:27 ` Gavin Smith
2019-10-15 20:20 ` P
2019-10-15 20:35 ` Gavin Smith
2019-10-15 20:40 ` Per Bothner
2019-10-15 21:00 ` Gavin Smith
2019-10-15 21:09 ` Per Bothner
2019-10-15 21:30 ` Gavin Smith
2019-10-16 1:39 ` Ricardo Wurmus
2019-10-19 20:31 ` Ludovic Courtès
2019-10-22 19:00 ` Gavin Smith
2019-10-22 20:18 ` Gavin Smith
2019-11-03 14:04 ` Ludovic Courtès
2019-11-03 15:37 ` Gavin Smith
2019-11-06 21:49 ` Ludovic Courtès
2019-04-03 21:21 ` Ludovic Courtès
2019-04-04 10:33 ` Gavin Smith
2019-04-02 15:31 ` Per Bothner
2019-04-03 21:11 ` Ludovic Courtès [this message]
2019-04-03 22:44 ` Per Bothner
2019-04-04 10:23 ` Gavin Smith
2019-04-04 16:02 ` Ludovic Courtès
2019-04-02 20:12 ` Ricardo Wurmus
2019-04-02 20:27 ` Ricardo Wurmus
2019-04-02 22:58 ` sirgazil
2019-04-02 22:10 ` Per Bothner
2019-04-02 23:09 ` sirgazil
2019-04-03 8:43 ` Gavin Smith
2019-04-03 14:23 ` sirgazil
2019-04-03 14:40 ` Per Bothner
2019-04-03 14:49 ` Ricardo Wurmus
2019-04-02 21:02 ` George Clemmer
2019-04-07 11:08 ` Gavin Smith
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ef6ipzef.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=bug-texinfo@gnu.org \
--cc=guix-devel@gnu.org \
--cc=per@bothner.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).