Writing Literate API Documentation in Emacs Org Mode
joseph8th.github.io
joseph8th.github.io
Until I found org-mode it really is world changing if I had picked up Doom Emacs for no other reason than org mode it would've been well worth it. I have now seriously considered trying to do literate program with org mode.
It's already seeped into every project I work on now has a notes.org where I keep kind of a stream of consciousness notes of what I am doing and copy and paste any code or command I have into it for future reference and it has already multipled my productivity.
I love org mode and for any person that is already a vimmer I recommend highly you pick up Doom Emacs and spend some time getting to become familiar with it, especially org mode and magit it really is world changing. I can't imagine ever going back.
Jupyter notebooks can provide a literate programming experience as well, but the plain-text experience of Org is something special.
They're not in the same league, although this isn't a knock on fugitive as they have different goals.
If you don't want to try magit¹ itself, then vimagit² is a reasonable approximation within vim. It gives you the same kind of workflow as magit, but doesn't quite feel as polished IME.
¹ You don't need to be an emacs user to use magit, you can treat magit as a standalone application.
So it is actually very difficult to do... But the results are Worth it to have software you can understand forever
The experience completely cured me of Knuth-style literate programming, fwiw. It's really great for making a lasting artifact about a program that's completely done. But I can count the number of programs I've worked on like that on zero fingers. Even this one isn't really done, but the cost of updating the essay along with the code discouraged me from working on it any more.
My emacs configuration is the exact opposite of a program that's completely done, but I find literate programming good for managing it's complexity.
> The experience completely cured me of Knuth-style literate programming, fwiw.
If it's not too much to ask, do you mind sharing some of the pain points?
To me, the point of literate programming is that you have a coherent (literate, if you well) document that explains how the program actually works, and the reason it's put together how it is. This is NOT an easy thing to write. It takes as much organization as the program itself. I found the document structure to be continuously in flux, as I updated the program to deal with new requirements. So either document would poorly structured, or I would spend a LOT of time keeping it good.
But then again, we can ask: if we cannot keep the program's document structure as a whole up-to-date, then are we really editing the program properly? A major risk of introducing bugs is that one may edit a part of a program without taking into account the broader context, such that the integrity of the program is lost, and literate programming (which forces us to update "the whole program" every time) can be considered a mitigation of this risk… so IMO the greater time that it takes to update the whole program could actually be a good thing, saving time in debugging or whatever.
Edit: Also, part of the trick is to put only as much as you think is really relevant in the "text" part: literate programming does not necessarily mean over-commenting everything (Knuth doesn't either), it's just an orientation that what you're doing is writing a document. It's ok for most of that document to be code, as long as you think you've presented it well enough.
In that regard, I'd say it is. True, we don't tangle and weave to separate artifacts. In fact, it doesn't tangle at all. However, I'd argue that in this case that isn't the point of the program. It's essentially a TUI to build an HTML artifact. Obviously we can't tangle `restclient` source blocks, but nor are we just dumping the results of `restclient` requests. Everything is piped into bash and post-processed by `jq` to clean up the final result for display.
That said, I accept that it's still not really "literate programming". It's literate API documentation.
I don't know how to properly version documentation, and how to prevent accidentally documenting responses for the wrong version number. Any recommendations?
Maybe including API version in the response so errors of that kind become very obvious ?
When I generate the `index.html` from Org, I point it at my local API, so there is never any doubt they are on the same version.
I know Org Mode is extremely tied in to Emacs' core, but if someone could figure out how to separate it into a vscode extension or something, that'd be really cool
You don't need much emacs for org-mode, especially if you keep the (admittedly dated) context-sensitve toolbar. Here's a cool (but short) infographic that gives you more than enough to go off of:
https://sachachua.com/blog/2013/05/how-to-learn-emacs-a-hand...
While this really exercises the markup features of org-mode and org-babel, wouldn’t literate programming have all this interleaved with the implementation at the API you’re documentating?
In my case, I'm documenting RESTful APIs for clients who want to write their own client code.