[O] Org-drill broken with Org 9.2
Hi,
When I try to run Org-drill, I get the backtrace below.
Others are seeing it too:
https://bitbucket.org/eeeickythump/org-drill/issues/62/org-drill-doesnt-work-with-org-mode-92
Ideas?
Thanks.
Debugger entered--Lisp error: (error "Invalid match tag: \"\"")
signal(error ("Invalid match tag: \"\""))
error("Invalid match tag: %S" "")
org-tags-expand("")
org-make-tags-matcher("")
org-map-entries((lambda nil (if (and (not (org-invisible-p)) (>
(org-current-level) drill-entry-level)) (progn (if (or (/=
(org-current-level) (1+ drill-entry-level)) (funcall test))
(progn (hide-subtree))) (setq drill-sections (cons (point)
drill-sections) "" tree)
(save-excursion (org-map-entries (function (lambda nil (if (and
(not (org-invisible-p)) (> (org-current-level)
drill-entry-level)) (progn (if (or (/= (org-current-level) (1+
drill-entry-level)) (funcall test)) (progn (hide-subtree)))
(setq drill-sections (cons (point) drill-sections)) ""
'tree))
(let ((drill-entry-level (org-current-level)) (drill-sections
nil)) (org-show-subtree) (save-excursion (org-map-entries
(function (lambda nil (if (and (not (org-invisible-p)) (>
(org-current-level) drill-entry-level)) (progn (if (or (/=
(org-current-level) (1+ drill-entry-level)) (funcall test))
(progn (hide-subtree))) (setq drill-sections (cons (point)
drill-sections)) "" 'tree)) (reverse drill-sections))
org-drill-hide-subheadings-if((lambda nil (let ((drill-heading
(org-get-heading t))) (not (member drill-heading
heading-list)
org-drill-hide-all-subheadings-except(nil)
(progn (org-drill-hide-all-subheadings-except nil)
(org-drill--show-latex-fragments) (condition-case nil (progn
(org-display-inline-images t)) (error nil))
(org-cycle-hide-drawers 'all) (prog1
(org-drill-presentation-prompt) (org-drill-hide-subheadings-if
'org-drill-entry-p)))
(unwind-protect (progn (org-drill-hide-all-subheadings-except
nil) (org-drill--show-latex-fragments) (condition-case nil
(progn (org-display-inline-images t)) (error nil))
(org-cycle-hide-drawers 'all) (prog1
(org-drill-presentation-prompt) (org-drill-hide-subheadings-if
'org-drill-entry-p))) (org-drill-unhide-clozed-text))
(progn (org-drill-hide-clozed-text) (unwind-protect (progn
(org-drill-hide-all-subheadings-except nil)
(org-drill--show-latex-fragments) (condition-case nil (progn
(org-display-inline-images t)) (error nil))
(org-cycle-hide-drawers 'all) (prog1
(org-drill-presentation-prompt) (org-drill-hide-subheadings-if
'org-drill-entry-p))) (org-drill-unhide-clozed-text)))
(progn (progn (org-drill-hide-clozed-text) (unwind-protect
(progn (org-drill-hide-all-subheadings-except nil)
(org-drill--show-latex-fragments) (condition-case nil (progn
(org-display-inline-images t)) (error nil))
(org-cycle-hide-drawers 'all) (prog1
(org-drill-presentation-prompt) (org-drill-hide-subheadings-if
'org-drill-entry-p))) (org-drill-unhide-clozed-text
(unwind-protect (progn (progn (org-drill-hide-clozed-text)
(unwind-protect (progn (org-drill-hide-all-subheadings-except
nil) (org-drill--show-latex-fragments) (condition-case nil
(progn (org-display-inline-images t)) (error nil))
(org-cycle-hide-drawers 'all) (prog1
(org-drill-presentation-prompt) (org-drill-hide-subheadings-if
'org-drill-entry-p))) (org-drill-unhide-clozed-text
(org-drill-unhide-text))
(progn (org-drill-hide-cloze-hints) (unwind-protect (progn
(progn (org-drill-hide-clozed-text) (unwind-protect (progn
(org-drill-hide-all-subheadings-except nil)
(org-drill--show-latex-fragments) (condition-case nil (progn
(org-display-inline-images t)) (error nil))
(org-cycle-hide-drawers 'all) (prog1
(org-drill-presentation-prompt) (org-drill-hide-subheadings-if
'org-drill-entry-p))) (org-drill-unhide-clozed-text
(org-drill-unhide-text)))
(progn (progn (org-drill-hide-cloze-hints) (unwind-protect
(progn (progn (org-drill-hide-clozed-text) (unwind-protect
(progn (org-drill-hide-all-subheadings-except nil)
(org-drill--show-latex-fragments) (condition-case nil (progn
(org-display-inline-images t)) (error nil))
(org-cycle-hide-drawers 'all) (prog1
(org-drill-presentation-prompt) (org-drill-hide-subheadings-if
'org-drill-entry-p))) (org-drill-unhide-clozed-text
(org-drill-unhide-text
(unwind-protect (progn (progn (org-drill-hide-cloze-hints)
(unwind-protect (progn (progn (org-drill-hide-clozed-text)
(unwind-protect (progn (org-drill-hide-all-subheadings-except
nil) (org-drill--show-latex-fragments) (condition-case nil
(progn (org-display-inline-images t)) (error nil))
(org-cycle-hide-drawers 'all) (prog1
(org-drill-presentation-prompt) (org-drill-hide-subheadings-if
'org-drill-entry-p))) (org-drill-unhide-clozed-text
(org-drill-unhide-text (org-drill-unhide-text))
(progn (if org-drill-hide-item-headings-p
(org-drill-hide-heading-at-point)) (org-drill-hide-comments)
(unwind-protect (progn (progn
[O] Org-drill broken with Org 9.2
Hi,
When I try to run Org-drill, I get the backtrace below.
Others are seeing it too:
https://bitbucket.org/eeeickythump/org-drill/issues/62/org-drill-doesnt-work-with-org-mode-92
Ideas?
Thanks.
Debugger entered--Lisp error: (error "Invalid match tag: \"\"")
signal(error ("Invalid match tag: \"\""))
error("Invalid match tag: %S" "")
org-tags-expand("")
org-make-tags-matcher("")
org-map-entries((lambda nil (if (and (not (org-invisible-p)) (>
(org-current-level) drill-entry-level)) (progn (if (or (/=
(org-current-level) (1+ drill-entry-level)) (funcall test))
(progn (hide-subtree))) (setq drill-sections (cons (point)
drill-sections) "" tree)
(save-excursion (org-map-entries (function (lambda nil (if (and
(not (org-invisible-p)) (> (org-current-level)
drill-entry-level)) (progn (if (or (/= (org-current-level) (1+
drill-entry-level)) (funcall test)) (progn (hide-subtree)))
(setq drill-sections (cons (point) drill-sections)) ""
'tree))
(let ((drill-entry-level (org-current-level)) (drill-sections
nil)) (org-show-subtree) (save-excursion (org-map-entries
(function (lambda nil (if (and (not (org-invisible-p)) (>
(org-current-level) drill-entry-level)) (progn (if (or (/=
(org-current-level) (1+ drill-entry-level)) (funcall test))
(progn (hide-subtree))) (setq drill-sections (cons (point)
drill-sections)) "" 'tree)) (reverse drill-sections))
org-drill-hide-subheadings-if((lambda nil (let ((drill-heading
(org-get-heading t))) (not (member drill-heading
heading-list)
org-drill-hide-all-subheadings-except(nil)
(progn (org-drill-hide-all-subheadings-except nil)
(org-drill--show-latex-fragments) (condition-case nil (progn
(org-display-inline-images t)) (error nil))
(org-cycle-hide-drawers 'all) (prog1
(org-drill-presentation-prompt) (org-drill-hide-subheadings-if
'org-drill-entry-p)))
(unwind-protect (progn (org-drill-hide-all-subheadings-except
nil) (org-drill--show-latex-fragments) (condition-case nil
(progn (org-display-inline-images t)) (error nil))
(org-cycle-hide-drawers 'all) (prog1
(org-drill-presentation-prompt) (org-drill-hide-subheadings-if
'org-drill-entry-p))) (org-drill-unhide-clozed-text))
(progn (org-drill-hide-clozed-text) (unwind-protect (progn
(org-drill-hide-all-subheadings-except nil)
(org-drill--show-latex-fragments) (condition-case nil (progn
(org-display-inline-images t)) (error nil))
(org-cycle-hide-drawers 'all) (prog1
(org-drill-presentation-prompt) (org-drill-hide-subheadings-if
'org-drill-entry-p))) (org-drill-unhide-clozed-text)))
(progn (progn (org-drill-hide-clozed-text) (unwind-protect
(progn (org-drill-hide-all-subheadings-except nil)
(org-drill--show-latex-fragments) (condition-case nil (progn
(org-display-inline-images t)) (error nil))
(org-cycle-hide-drawers 'all) (prog1
(org-drill-presentation-prompt) (org-drill-hide-subheadings-if
'org-drill-entry-p))) (org-drill-unhide-clozed-text
(unwind-protect (progn (progn (org-drill-hide-clozed-text)
(unwind-protect (progn (org-drill-hide-all-subheadings-except
nil) (org-drill--show-latex-fragments) (condition-case nil
(progn (org-display-inline-images t)) (error nil))
(org-cycle-hide-drawers 'all) (prog1
(org-drill-presentation-prompt) (org-drill-hide-subheadings-if
'org-drill-entry-p))) (org-drill-unhide-clozed-text
(org-drill-unhide-text))
(progn (org-drill-hide-cloze-hints) (unwind-protect (progn
(progn (org-drill-hide-clozed-text) (unwind-protect (progn
(org-drill-hide-all-subheadings-except nil)
(org-drill--show-latex-fragments) (condition-case nil (progn
(org-display-inline-images t)) (error nil))
(org-cycle-hide-drawers 'all) (prog1
(org-drill-presentation-prompt) (org-drill-hide-subheadings-if
'org-drill-entry-p))) (org-drill-unhide-clozed-text
(org-drill-unhide-text)))
(progn (progn (org-drill-hide-cloze-hints) (unwind-protect
(progn (progn (org-drill-hide-clozed-text) (unwind-protect
(progn (org-drill-hide-all-subheadings-except nil)
(org-drill--show-latex-fragments) (condition-case nil (progn
(org-display-inline-images t)) (error nil))
(org-cycle-hide-drawers 'all) (prog1
(org-drill-presentation-prompt) (org-drill-hide-subheadings-if
'org-drill-entry-p))) (org-drill-unhide-clozed-text
(org-drill-unhide-text
(unwind-protect (progn (progn (org-drill-hide-cloze-hints)
(unwind-protect (progn (progn (org-drill-hide-clozed-text)
(unwind-protect (progn (org-drill-hide-all-subheadings-except
nil) (org-drill--show-latex-fragments) (condition-case nil
(progn (org-display-inline-images t)) (error nil))
(org-cycle-hide-drawers 'all) (prog1
(org-drill-presentation-prompt) (org-drill-hide-subheadings-if
'org-drill-entry-p))) (org-drill-unhide-clozed-text
(org-drill-unhide-text (org-drill-unhide-text))
(progn (if org-drill-hide-item-headings-p
(org-drill-hide-heading-at-point)) (org-drill-hide-comments)
(unwind-protect (progn (progn
Re: [O] Regression bug in tangle/weave
Eric Schulte schulte.e...@gmail.com writes: Hi, Indeed this example below no longer works, however I believe the new behavior is both desired and permanent. I'll explain and include an option for how your example could be restructured to work with the new code. We ran into problems automatically removing trailing newlines from code block bodies as in some languages (looking at you Python and Haskell) things like trailing newlines are of syntactic importance. In your example this behavior results in the insertion of newlines after file-name and file-version. Babel is careful to preserve line prefixes when expanding references in comments, so it then reproduces the # Generated from portion of that line for every line of the expanded noweb references. I would suggest the following alternatives, either using a data references in stead of a code block reference as in the file-version example below, or using an evaluated code block as in the file-name example below. Hope this helps. Oh dear. Am I to blame for this? When I reported the newline issue, somewhere in the back of my mind I knew it probably would have some ugly consequences. Now I see them. An evaluated code block seems inelegant/confusing if one intends to export that code as part of the document. A data reference seems OK, but I take it you can't have references within it? Unfortunately, I see no easy solution...
Re: [O] Literate Programming - Continue a Source Block?
Sebastien Vauban wxhgmqzgw...@spammotel.com writes: The only case that pops up to my mind now, of such a use case where overwriting could be needed (well, let's say useful) is for some pedagogical document that one would write, where code is constructed from a simplistic (and buggy) approach to a correct one. One could say: the code to do that is this one, and show the block contents. Then, discover problems to it, explain them in the document, and make a new version of the block with the same name (for tangling reasons). Then, highlight some limitations of the new code, fix them in a new block with the same name, etc. Does that mean it needs to be implemented? Up to you... I gave a similar example earlier, and I think Eric said that can be handled by just changing the tangle header for the code you overwrite. Not as convenient, though.
Re: [O] Literate Programming - Continue a Source Block?
Eric Schulte schulte.e...@gmail.com writes: How about the following solution, which is based on a new :noweb-ref header argument. When expanding ``noweb'' style references the bodies of all code block with /either/ a block name matching the reference name /or/ a :noweb-ref header argument matching the reference name will be concatenated together to form the replacement text. By setting this header argument at the sub-tree or file level, simple code block concatenation may be achieved. For example, when tangling the following Org-mode file, the bodies of code blocks will be concatenated into the resulting pure code file. Hi, Your example is not completely clear. I noticed you didn't put any names for the source blocks that use the noweb-ref. Is it necessary not to name them, or can one name them but their names will still have to be unique and are orthogonal to concatenation (i.e. they have names, but the concatenation is due to whatever the argument of noweb-ref is)? I think either way, this solution serves my purpose. My original suggestion was to have a header whose value would be append to allow for concatenation if the name matches a previous source block. It seems your solution above is the same except instead of looking at the name of the source block, it looks at the argument of noweb-ref. Overwriting is still not supported, but I don't know if that's all that important (I don't have an immediate need for it). And noweb by default did not have it either, so perhaps it's not needed for most tasks (OTOH, you may want to think about what the best solution is if later on you decide to add overwriting capability). Thanks. Hope to see this or something like it soon.
Re: [O] Literate Programming - Continue a Source Block?
Eric Schulte schulte.e...@gmail.com writes: It would be possible to also implement the concatenation behavior during noweb expansion, however I'd prefer to first wait for a response to my recent other email to this thread asking for a more clear explication of existing noweb behavior. The only remaining times when such concatenation behavior could be implemented would be during block reference expansion, and during block evaluation, but I think expanding at those times would be unnecessary and confusing. I'm having trouble understanding the difference between what you discuss in the first paragraph and in the second. What's the difference between noweb expansion and block reference expansion? As for actual noweb behavior, I don't really know - will have to play with it and let you know...
Re: [O] Literate Programming - Continue a Source Block?
Eric Schulte schulte.e...@gmail.com writes: Rather than feeling our way forward step by step it seems that simply following the behavior of noweb would both 1. allow for easy transition between noweb and babel 2. benefit from the years of experience and design accumulated in the noweb project Does anyone on this list know the noweb system well enough to specify its behavior in this regard, and to describe what functional changes would be required to bring Babel into line with noweb behavior? Looking at the basic functionality: ...= starts a code block. Further uses of it will just append. No delimiter for end (it ends when you start another code/doc block). It can be referenced using ... (without the = symbol). The location of the reference is not relevant. So by default, no overwriting or ordering. However, noweb is extensible, and Achim linked to the syntax one can use to extend it. I haven't read those details. Hope that helps.
Re: [O] Literate Programming - Continue a Source Block?
Eric Schulte schulte.e...@gmail.com writes: Could you try the attached example file? I first evaluated the following elisp code to set the combination variable's value to append. Your example works if there are no noweb references. See the modified one where I have noweb references. Note that when expanding the reference, it inserts only the first block it finds. #+begin_src emacs-lisp :tangle yes :noweb yes foo Random text bar #+end_src * continued code blocks :PROPERTIES: :tangle: yes :comments: yes :END: #+srcname: foo #+begin_src emacs-lisp (message foo:%S 1) #+end_src #+begin_src emacs-lisp (message un-named) #+end_src #+srcname: bar #+begin_src emacs-lisp (message bar:%S 1) #+end_src #+srcname: foo #+begin_src emacs-lisp (message foo:%S 2) #+end_src #+srcname: bar #+begin_src emacs-lisp (message bar:%S 2) #+end_src #+begin_src emacs-lisp :tangle no :results silent (with-temp-buffer (insert-file-contents scraps.el) (eval-buffer)) #+end_src
Re: [O] Literate Programming - Continue a Source Block?
Eric Schulte schulte.e...@gmail.com writes: Hi Neeum, Thanks for your feedback. Your point is well taken about the flexibility of header arguments, and the ability of a header argument based solution to overwrite blocks. I would mention that variables such as the newly introduced `org-babel-tangle-named-block-combination' may be easily set on a per-file bases using file local variables---basically adding a line like the following to the top of your Org-mode file. Somehow I couldn't get your new function to work. The variable is set to append, and I removed all org-modes from my system except the latest from git. I even ensured that this code gets executed: (append (mapconcat #'identity named \n)) However, the output I get is the same as before - it just uses the first source block. Incidentally, why do we need \n as a separator? What if I wanted to do (in Python) def func(a, b, func_args): stuff In other words, I want to add more arguments later on. Wouldn't a \n mess things up here? Thanks.
Re: [O] Literate Programming - Continue a Source Block?
Eric Schulte schulte.e...@gmail.com writes: I like the concision of the =original-name syntax used by noweb, but I would lean towards the use of a :noweb-append type header argument as suggested above because currently the names of blocks in Babel carry no semantic content and I'd prefer to leave it this way. I suppose it may also break compatibility in case someone out there uses the =symbol. Had it been thought of earlier, I would have preferred the default behavior being append if you have multiple blocks of the same name, and an explicit option *not* to append but to overwrite, but your idea makes the most sense with respect to preserving backward compatibility. In addition to append, there probably should be another option for overwriting instead of appending (neither is possible right now). I've just pushed up a patch which implements optional block combination during tangling. Specifically a new customization variable named `org-babel-tangle-named-block-combination' is introduced which can take the following values This does solve the problems I have, but I think the noweb-append header option discussed earlier is much more flexible. The potential problems with a custom variable is that it can't be set at a per-buffer or per-document level. I was thinking along the lines of: :noweb-append option where option is one of: - nil (the default) - append (appends to the block of the same name as it is up to that point in the document - acts as nil if this is the first block of that name). - overwrite (overwrites the block as it is up to that point - acts as nil if this is the first block). I think these three provide all the abilities of what you proposed, but allows for much more. Some additional benefits: 1. Can be set at a per-buffer level or a per-block level. 2. Can selectively append/overwrite. One scenario where this would be useful is where you may have had some source blocks that had been appended, but then later on as the project evolves, you decide to rewrite much of that code. You can then just do an overwrite (i.e. erases all that you had up to that point), and then again allow for the new code to be evolved with possible future appends (so multiple appends/overwrites in one document). You may have reason to keep the old code in the document for some reason or other. If that didn't make sense I can explain in more detail. Hopefully this gets at the behavior you're after. I'd be interested to hear any thought you have on this new functionality. I don't want to make it sound like I'm complaining above. What you've proposed probably takes care of my current needs (and I imagine is a bit easier to code than what I've proposed) - but I just think having a new header for the source block would make it much more flexible. I haven't yet tried the new patch - I'll have to figure out how to do a custom babel install (at the moment I get it via orgmode which is installed system-wide). Is it possible for me to just install babel in my custom emacs directory and not have it impact other aspects of org-mode? Thanks for the quick commit! -- My neighbor has a circular driveway. He never leaves home.
Re: [O] Literate Programming - Continue a Source Block?
Achim Gratz strom...@nexgo.de writes: Eric Schulte schulte.e...@gmail.com writes: append the bodies of all blocks of the same name are appended during tangling several blocks with the same name seem a bit dubious, would it not be cleaner to have an index part to the block name and a range expression for the concatenation during tangling? I might want to tangle them in different order than their appearance in the source, for instance. For my purposes, an index would be too much to maintain, and while I wouldn't mind it as an option, I wouldn't want to *have* to use them if all I want is to append and/or overwrite. The solution I proposed in my response to Eric may meet you halfway there in some ways. When I initially wrote about this problem, my goal was simply to enable what could easily be done with noweb (and of course, I actually had a need for it). I actually have very little experience with LP, so I don't know in practice what will work and what won't. The initial benefit that I can see with indexing is that one may want to add some lines in the middle of a block. However, this can only really work if you just happen to end/begin your source blocks at that point. If you didn't know in advance that you'd add some lines in the middle, then you likely didn't end/begin your blocks at that point, and you'll have to go and artificially begin/end your blocks there. This may seem confusing to a reader, so it makes sense to put an explicit noweb style reference. If, on the other hand, you knew it in advance, you probably should put the noweb reference any way. My comments are from the perspective of my use case for LP, and I can see people may use LP for other reasons, so if you have a better scenario, let us know.
Re: [O] Literate Programming - Continue a Source Block?
Sebastien Vauban wxhgmqzgw...@spammotel.com writes: Hi Neeum, Neeum Zawan wrote: With noweb, one can continue a source block that one started earlier. Can this not be done with Babel? If not, I'm struggling a little with how to do LP using Babel... Of course, this can be done here as well: simply reuse the same tangle target (file), and blocks are concatenated in the order they appear. But this will only allow me to append to the end of the file (up to that point), correct? I want to append to a source block that may be in the middle. Consider the following example: (Begin-example) #+BABEL: :noweb yes * Outline The structure of the configuration file will be: #+srcname: outline #+begin_src emacs-lisp :tangle .emacs :exports code ;; Store configurations that impact appearance visual-config ;; Languages configurations lang-config ;; GNUS configurations gnus-config #+end_src * General Appearance This section controls the general appearance (color of cursor, fonts, etc). #+srcname: visual-config #+begin_src emacs-lisp :exports code ;; Config here. #+end_src * GNUS configuration #+srcname: gnus-config #+begin_src emacs-lisp :exports code ;; Config here. #+end_src * Languages #+srcname: lang-config #+begin_src emacs-lisp :exports code python-config perl-config #+end_src ** Python Now here's where the problem begins. I want to add some configurations that impact some Python settings. I can dump those in python-config. However, I also want to add some visual settings for python-mode (change font colors, etc). For whatever reason, I think that part should go into visual-config. How do I now append the relevant portion to visual-config while I'm in _this_ portion of the org document? (End-example) The above is somewhat artificial, but in a proper programming project something like this will occur frequently: A new feature will be added at some later point and I'll want to update various blocks of code. Second solution: create one sole block that will be tangled, and which contains your other blocks (using the ref syntax), in the order you want. I had thought of this, but I find it somewhat lacking. Consider my example above. I could have created a visual-python in my visual-config block. However: 1. That requires me to know I'm going to need it later when I write visual-config. 2. If I didn't know I'd need it, I'd have to continually modify various parts of the org document every time I add a new feature to my code. I find this suboptimal and error prone. 3. For me, one of the main motivations to do LP is to document the evolution of the project, such that someone else can read the document and understand. Part of this is that I want all aspects of a single feature to appear under a single heading. When the reader reads the document, he shouldn't have to see too many aspects of the code early on that will be explained much later in the document. Now the original noweb allows what I'm asking for. If you begin a source block with a name of an existing block but append an = symbol, it knows to append to that source block. It would be great if org-mode could add that capability. Another approach is that if multiple source blocks with the same name are found, the default behavior is to concatenate all those source blocks together (and then add a header option for overwrite if the user wanted to overwrite instead of append). Thoughts?
Re: [O] Literate Programming - Continue a Source Block?
Eric Schulte schulte.e...@gmail.com writes: Second solution: create one sole block that will be tangled, and which contains your other blocks (using the ref syntax), in the order you want. I had thought of this, but I find it somewhat lacking. Consider my example above. I could have created a visual-python in my visual-config block. However: 1. That requires me to know I'm going to need it later when I write visual-config. nit picking here, but while this does require a small edit to visual-config, there is no need for prior knowledge of the need for visual-python. 2. If I didn't know I'd need it, I'd have to continually modify various parts of the org document every time I add a new feature to my code. I find this suboptimal and error prone. Technically only one edit per new block introduced, which does not seem overly onerous. In this case, yes. In a real programming project, it could be a number of them. For example, I may have a code block dedicated to imports/includes which I want to be on the top of the file - and I may have to append to that when adding a new feature. And then the actual code for the new feature may require edits to other parts of one's program. Ideally, everything should be decoupled, but reality rarely follows the ideal ;-) Now the original noweb allows what I'm asking for. If you begin a source block with a name of an existing block but append an = symbol, it knows to append to that source block. It would be great if org-mode could add that capability. I agree, and the functionality you describe shouldn't be overly difficult to implement. I like the concision of the =original-name syntax used by noweb, but I would lean towards the use of a :noweb-append type header argument as suggested above because currently the names of blocks in Babel carry no semantic content and I'd prefer to leave it this way. I suppose it may also break compatibility in case someone out there uses the =symbol. Had it been thought of earlier, I would have preferred the default behavior being append if you have multiple blocks of the same name, and an explicit option *not* to append but to overwrite, but your idea makes the most sense with respect to preserving backward compatibility. In addition to append, there probably should be another option for overwriting instead of appending (neither is possible right now). Also, just on the side, I'm not sure it's documented anywhere what happens if you have multiple source code blocks of the same name. At the moment, it seems only the first is used (I would have expected the last). Thanks for the motivating example and the thorough explanation of behavior. I'll certainly put this on my long-term development queue, however, that does not guarantee an implementation in the near future. If anyone is interested in this functionality and is up for writing some elisp I am happy to offer advice and code pointers immediately. Wish I knew elisp. Anyway, hopefully someone will get it done one day. Thanks.
[O] Literate Programming - Continue a Source Block?
Hi, With noweb, one can continue a source block that one started earlier. Can this not be done with Babel? If not, I'm struggling a little with how to do LP using Babel... Thanks.
