Hello, Kaushal Modi <kaushal.m...@gmail.com> writes:
> I was playing with Org Tangle header-args inheritance and came up with > this example: > > ===== > > #+property: header-args :tangle yes > > At Org level 0. > > * Heading 1 > :PROPERTIES: > :header-args: :tangle foo.el > :END: > At Org level 1. > > #+name: block1 > #+begin_src emacs-lisp > > (message "this will be tangled to property_drawer2.el") > #+end_src > ** Heading 1.1 > :PROPERTIES: > :header-args:emacs-lisp: :tangle no > :END: > At Org level 2. > > Only the emacs-lisp block will *not* be tangled from this subtree. > > #+name: block2 > #+begin_src emacs-lisp > > (message "this block will *not* be tangled") > #+end_src > > But the below Nim block will tangle fine (though incorrectly to the > foo.el file!). It isn't incorrect. You specified "foo.el". Use ":tangle yes" if you want to let Org decide about the extension. > Though, the below /block3/ appears *above* /block1/ in > the tangled file foo.el. > > #+name: block3 > #+begin_src nim > > echo "this block will be tangled to property_drawer2.nim" > #+end_src > ===== > > Tangling this (C-c C-v t) gives this foo.el file: > > ===== > echo "this block will be tangled to property_drawer2.nim" > > (message "this will be tangled to property_drawer2.el") > ===== > > Ignoring that Nim code gets inserted into the Emacs-Lisp file because > of incorrect :tangle header-args under Heading 1, why is the block3 > code appearing above block1? > > Is this a bug? It is. Fixed. Thank you. Regards, -- Nicolas Goaziou