This announcement is pretty exciting because it reveals a new-to-me take on literate programming. The style is to store a single file as a source, and render disparate parts of that file in different buffers in a mode correct for the content.
For example you may have an Emacs Lisp file serve as the source and two separate buffers, one Emacs Lisp and one Organization (Mode), to work on the content, with all of the mode-specific assistance.
Is it a new idea? It is new to me and I am curious to find out about other approaches people have taken to realize this style.
Grant Rettke: The Lenticular Text Style of Literate Programming http://t.co/bWiUIXwthm
I would love to know if it is not novel. I looked hard before I wrote it, but couldn’t find anything.
When I started writing it, I thought that it would be too slow, since it has to percolate changes, but actually even the first naive implementation worked okay. The limitation, of course, is that the transformation has to be simple enough; a full literate style tangling would be very hard to implement.
Did you really look that hard?
Here a citation from the Outorg README (https://github.com/tj64/outorg), a library that started with version 0.9 in february 2013 and was not not kept as a secret in the Org-mode/Emacs world:
“Thus org-mode and programming-mode are just two different views on the outshine-style structured source-file, and outorg is the tool to switch between these two views. When switching from a programming-mode to org-mode, the comments are converted to text and the source-code is put into src-blocks. When switching back from org-mode to the programming-mode, the process is reversed – the text is outcommented again and the src-blocks that enclose the source-code are removed.”
So the general idea/concept of “two different views (code vs. text) on the same file” is identical here and pre-dates lentic by two years or so. It’s the implementation that is completely different and makes these libraries entirely different beasts.
Outorg itself was pre-dated a few month by Poporg from François Pinard, with a similar basic idea (tangling sucks when the code is much more important then the text, so why not reverse the process), but more limited scope:
“poporg is a small Emacs Lisp project, to help editing program string or comments using Org mode.
Literate programming with Org is often presented as mixing programs snippets within an Org document, with tools to extract pure programs out of the Org files. I would prefer it the other way around: mixing documentation snippets within program source code, with tools to extract pure Org documentation from the source files.”
https://www.wisdomandwonder.com/article/10376/outorg-lets-you-convert-source-code-buffers-temporarily-to-org-mode-for-comment-editing
Thank you Thorsten
Grant Rettke: The Lenticular Text Style of #LiterateProgramming: http://t.co/Z7FA1ajFqP #emacs #orgmode
PHIL LORD:
Your library satisfies a very interesting use case. The pattern is quite recognizable from a software engineering perspective, but, I’ve never seen it for editing! Not surprising, either, that it appeared with Emacs :).
Thanks Grant for bringing attention to this very useful and eminently novel idea from Phil Lord.
One use case I always missed in regular word processors is being able to extract all quotes, all references, all text in italics, or all indented comments, and so forth. With lentic, I can see being able to pull such sub-parts of documents not related to usual structural elements like headings and chapters, as extremely useful. I can envision by products of untangling through lentic to include TOC, indexes, definitions, quotes, references, etc.
@rrrrrrrix Just in case you haven’t seen yet: http://t.co/NHP77FOycJ
@SKIP Lentic replicates the entire contents of the buffer. However, it leaves text properties alone, so I think you could achieve what you want by simply making all of the text that you don’t want to see invisible in one view. You might be able to use narrowing.
I had a specific use case in mind when I wrote lentic, but I am aware that potential use cases are much wider — at least as wide as indirect buffers certainly.