If I understand correctly, it isn't mainly intended for
interactive work, but to create files that can be compiled or
processed
in other ways.
Yes.
Of course, it could be that one can combine both. Provide a way to
interactively edit a file, and create it right there, but also
convert
the whole document.
As I said before, the main problem I see with literate programming is
the fact that you have the choice between two evils:
1) Force all developers to use the same literate programming tool:
the TeXmacs documents become the actual source code.
2) Clobber the native ASCII source code with special comments which
contain directives for the literate programming tool.
I fully understand that making a decision on which evil you prefer
naturally leads to two different blends of literate programming tools.
Nevertheless, it might still be best to have a tool which
can operate in both modes: use TeXmacs documents as source code,
or use native source code.
Another challenge is to reduce the clobbering in 2) as much as
possible.
One idea is to make TeXmacs grammar-aware, so that searching for a
particular
piece of code becomes very robust, even in absence of special
directives.
Unfortunately, this does not entirely solve the problem, because an
external
person might delete or rename our particular piece of code using
another editor.
Actually, the external person is not even be aware of the fact that
our piece of code was annotated.
Anyway, at a certain point, I will dive into these issues.
At the moment, I will just try to follow the ongoing experimentations.