Chris,
Yes, I am also unhappy with the use of numbering to order chunks, but
the traditional LP mechanism of using substitution of named chunks has
some major flaws I have not figured out how to address.
The basic problem is that it can be used as a mechanism for code reuse,
probably will be if it is present. This is not necessary (code reuse
like this probably means poor use of the code reuse mechanisms of the
programming language in any case), hides the fact that the code is
reused from debugging and performance tools that rely on the source
code, and makes the task of untangling much harder, and impossible to
completely automate. Consider a program in which the same chunk appears
twice in the tangled source code. Using a debugger, you find a bug in
the chunk. You fix it in the source code, but only in one place. You
then find another bug, or even the same bug in a different guise, and
fix it differently in the other appearance. What is the untangler
supposed to do with the result? Which new version do you want? Do you
want the changes merged? Do you actually want both versions, and if so,
how does it edit the org-mode document to include them?
Yes, I know, from an LP purists point of view, the untangler is an
abomination. Unfortunately, few (if any) code development tools
(debuggers, performance analyzers, etc.) support debugging or analysis
of source code embedded in CWEB, noweb, or org-mode text files. This, to
me, is a deal-breaker. With an untangle command, I can write my code in
an org-mode file, tangle it and get emacs buffers with all C, headers,
makefiles, java, or whatever code in it, use emacs's extensive code
development tools (eg the emacs front end to gdb) to build and debug it,
and pull the source code back into the org-mode file when the bugs are
fixed. In fact, the code development tools do not even need to be
embedded in emacs; anything tools can look at a traditional source file
becomes useful.
There is an additional problem, although one that can be solved by "just
doing more work." At present, org-tangle can use the existing org-mode
export code to do all necessary weaving. org-mode, in turn, takes
advantage of the many independently supported modes for each language to
format them properly. If we introduce a new syntax (for substitution)
inside the literal blocks, it means that we will need an org-weave that
can properly format each language. I am not sure how practical this is;
I am certainly not that ambitious.
It may be a little while before my itself makes an appearance. Not only
do I need to wait for my employer to figure the legal stuff, I have also
received enough feedback that I want to address issues better before
anyone else is tempted to use the code.
-Eric
--
Eric H. Neilsen, Jr.
http://home.fnal.gov/~neilsen
_______________________________________________
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode