On 02/09/2016 10:44 AM, Gavin Smith wrote:
Other problems come to mind: * Intermanual links: locally installed manuals should be preferred.
The easiest is if you assume the manuals are located in the same "logical" directory. By "logical" I mean you could also have a tree of symlinks: manuals/elisp.html -> whatever manuals/emacs.html -> whatever Assume you're reading the Emacs manual, with the location file:///whatever/manuals/emacs.html . You click on a link <a href="elisp.html#Buffers">Buffer functions</a> . The browser doesn't know about symlinks, so it resolves elisp.html relative to the "current" URL, yielding file:///whatever/manuals/elisp.html
* Search path for manuals.
Search paths are more difficult. I don't know a way to trap "failing" location changes. However, it is possible to add an event handler for the "click" event. Its handler can do whatever you want to do - subject to whatever JavaScript lets you do - which depends on your browser environment.
* How the locally installed HTML pages are accessed, in a standard web browser or a special documentation viewer that happens to use HTML as its format.
As the author of DomTerm (http://domterm.org), I think that would make a great framework for an info program: It's a general-purpose terminal emulator, based on web technologies. My idea is for the info program to check if it is running under DomTerm, and if so it "loads" the html document into an iframe of the same DomTerm instance. The info program can use escape sequences to communicate with the documentation iframe. For example, it can trap clicks and search for the correct manual. However, we probably still need an info solution for plain vt100-style terminals. One idea is for the info program to call a little helper program which would use libxml to convert the html into plain text, including line-wrapping as appropriate. (That is one reason that html output should be well-formed XML.) -- --Per Bothner [email protected] http://per.bothner.com/
