Hi Eric, Thanks a lot for your quick reply and fix. Getting the git repo version scares me a bit, but I guess I'll just have to take the plunge! Here we go :)
Thanks again, Tomas On Thu, Dec 29, 2011 at 16:51, Eric Schulte <eric.schu...@gmx.com> wrote: > Tomas Grigera <tgrig...@gmail.com> writes: > >> Hi list, >> >> This is my first post, so just let me say first that I have been using >> org-mode for 10 months or so and I love it. It's an exceptional >> package, and before I ask my question I would just like to thank >> Carsten, Bastien, and the community for the great work and for >> sharing. >> >> Now my question: I am trying to extract code from a .org file by >> tangling with noweb-style references. As I understand from the manual, >> if I write <<foo>> in a code block, the line will be expanded with the >> code block named foo. This name I can set with #+NAME: or with the >> :noweb-ref header argument. Both ways work for me, except that I >> cannont set the :noweb-ref argument through a property. >> >> The following example is almost verbatim from the manual: >> >> #+BEGIN_SRC sh :tangle yes :noweb yes :shebang #!/bin/sh >> <<fullest-disk>> >> #+END_SRC >> >> * the mount point of the fullest disk >> >> ** query all mounted disks >> >> #+HEADER: :noweb-ref fullest-disk >> #+BEGIN_SRC sh >> df \ >> #+END_SRC >> >> >> ** strip the header row >> :PROPERTIES: >> :noweb-ref: fullest-disk >> :END: >> #+BEGIN_SRC sh :noweb yes >> |sed '1d' \ >> #+END_SRC >> >> >> If I understand correctly, tangling should produce a file which is a >> concatenation of the two code blocks. However, when I do >> org-babel-tangle, only the first block is inserted. Am I doing >> something wrong? >> >> I'm with emacs 23.2.1 and org-mode 7.8.02 >> >> Thanks in advance, >> >> Tomas >> > > Hi Tomas, > > You are correct the behavior described above is a bug introduced by a > fairly recent commit of mine which switched to using regular expressions > when resolving noweb references in an attempt to decrease the time > required to tangle code blocks (which can be significant in large code > blocks). > > However correct performance is more important than fast performance. > I've just pushed up a patch which fixes the bug you've described, and > hopefully doesn't slow down the tangling process too significantly. > > Cheers, > > -- > Eric Schulte > http://cs.unm.edu/~eschulte/