[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Any interest in using HTML for locally-installed Texinfo documentati
Re: Any interest in using HTML for locally-installed Texinfo documentation?
Wed, 06 Nov 2019 22:49:26 +0100
Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)
Gavin Smith <address@hidden> skribis:
> On Sun, Nov 03, 2019 at 03:04:27PM +0100, Ludovic Courtès wrote:
>> Does the reader fall back to an on-line copy of manuals that are
>> unavailable locally? That would be nice, though it should probably
>> first ask for user consent.
> It doesn't do that yet. It would have to look at an htmlxref.cnf file or
> equivalent, as the URL for the remote manual should not be in the locally
> installed documentation.
Sounds like a plan.
>> I’d love to see an appropriate CSS applied by default to all the locally
>> installed manual. Perhaps the WebKitGTK code could “force” a CSS to
>> each HTML page?
> It is possible using webkit_web_view_new_with_user_content_manager.
>> In the future, it’d be great to have syntax highlighting like we have at
>> but… I guess that’s another story. :-)
> How is that done? Are the HTML file post-processed somehow?
Yes, it’s a bit ugly: we post-process the HTML in search of
blocks (which correspond to @lisp) pass them through
guile-syntax-highlight. There’s a bit of CSS for the rainbow
>> What would be the next steps for you? Do you plan to have this new
>> reader released as part of the next Texinfo release, or as a separate
> It would probably be for a separate package. At the moment the program
> is called "infog" standing for "Info GTK".
> There are various things that need to be done before it is ready for
> * Allow installing the program, so that it can be run via PATH
> * Handle external links in a web browser (using some kind of user
> desktop default)
> * I'd like to make the index search completions in a separate pane
> rather than a pop-up menu, as in the "devhelp" program.
> * Perhaps support for tabs
> * The program uses a deprecated API in the WebKitGTK library to access
> same thing, but the documentation is not that helpful on how to do this.
> * There is no text search facility in pages
> * Standardize a location for installing HTML manuals. What the GNU
> Coding Standards currently says about "htmldir" is insufficient, as a
> manual may have a different name to the package it is part of.
> * It would be nice if the text input for a new window could be done as
> some kind of pop-over widget rather than in a separate dialog box.
Good. I don’t think any of these are a showstopper, except perhaps the
bit about standardizing HTML installation (and getting distros to
actually do that!). Other than that, your program is already useful as
it is, IMO.
> I only have a few hours a week to spend on this, so it could take me
> some time to get through it.
> I have been looking at tweaking the output of texi2any so the HTML looks
> better in this browser, including using mini-tables of contents instead
> of menus, and the table of contents linking to the top of a page rather
> than to an anchor a little down the page.