Emacs, of course, has always described itself as self-documenting because it has an integrated documentation system. With my new creation, lenticular text, (n.d.a) though the world changes slightly. I can now write rich documentation embedded into the code base of my package, and can do this without comprimising either the documentation or coding environment.
For the 0.7 release of lentic (n.d.b) I added support for generating this documentation automatically on the fly from the source code. This can be viewed either internally in Emacs with EWW, or externally with a browser. In the latter case, I have used org-info.js (n.d.c/) which gives an info-like and navigable experience to the manual.
As yet, this process is not perfect, and the output is not ideal, but it still seems to me to be very nice. It is certainly something that I wanted to use for m-buffer (n.d.d) So I’ve extended lentic so that its documentation system can work for any package. Much to my amazement, it’s already is use by others (n.d.e) which has to be a good sign after such a short time span.
The main issue in making lentic-doc generic is working out how to
compile the completed org-mode files into HTML. I had already considered
trying to the “main” file for a package (so, lentic.el for lentic or
m-buffer.el for m-buffer). But, as I discovered with lentic this does
not work that well; instead I use a single top level file which imports
everything else. To enable this lentic-doc uses the following technique:
first it looks for a variable called
package-doc describing how to
compile the package documentation; if that fails, lentic looks for a
package-doc.org in which case that is used. The main entry
points are two functions
lentic-doc-eww-view which show the documentation in the respective
There has been a lot of discussion about documentation format on the Emacs-devel mailing list recently. One common complaint was that texinfo 5 is rather too slow, taking a considerable time to compile for Emacs. Now, at first sight it would appear that moving to a lentic/org mode solution would make this worse, as the combination of the two will be much slower than even texinfo. However, lentic and org have one advantage over texinfo — they are entirely implemented in Emacs lisp, so anyone using Emacs also has the ability to generate the documentation from source; this means that the documentation can be built up lazily, on-the-fly as it is requested.
This works straighforwardly for a single package at a time — on request Emacs generates the documentation for lentic or m-buffer and displays. This still leaves the problem of cross-links between the different packages, of course. If I want to hyperlink from lentic to m-buffer, then I need to ensure that the m-buffer documentation is generated. Not so easy if the documentation is being viewed inside a browser.
Fortunately, Emacs provides a solution. Actually, two, as there are now two packages implementing a webserver for Emacs. By using an Emacs web server, I can handle any requests for package documentation, generating them on-the-fly if necessary. It turns out to be relatively simple too, as you can see here: https://github.com/phillord/lentic-server.
Of course, lentic-server is just a work in progress and far from complete, but it is pleasing none the less. The use of lentic has allowed me to tie together Org and Emacs-lisp, and to make rich documentation environment from technology that already exists.
The versions of lentic and lentic-server described here are available on MELPA (n.d.f/)