Hi Eric, Eric Schulte wrote: > "Sebastien Vauban" <wxhgmqzgw...@spammotel.com> writes: >> Nicolas Goaziou wrote: >>> "Sebastien Vauban" writes: >>>> In fact, what you expect is that putting a tag ":noexport:" on a subtree >>>> would >>>> propagate the option ":eval no-export"[1] to all code blocks beneath it. >>>> That's >>>> the one which inhibits code block evaluation during export (but allow >>>> interactive evaluation). >>>> >>>> I really don't have any strong opinion about this, even if, without further >>>> thinking, I'd favor the same behavior as the one you expected. >>> >>> To answer the OP, :noexport: tag is related to export, not to >>> src-blocks. There are already other ways to disable code evaluation on >>> subtrees. It may be useful, as in your case, to have their behaviour >>> linked, but again, sometimes not. >>> >>> It's often better to keep separate things, well, separate. >> >> To see whether there is more weigh toward a solution or the other, I would >> formulate the question this way: >> >> are there real use-cases where one would want to *not* export a subtree >> (by tagging it), though to *well* evaluate the code blocks it contains? > > #+Title: Example > > Results in heading "first" are generated by un-exported code blocks in > heading "second". > > * first > > Things my adviser cares about. > > #+RESULTS: foo > : like some result: 3 > > * second :noexport: > > Things my adviser does not care about, but which I need to keep, like > minutiae of generating the result. > > #+Name: bar > - foo > - bar > - baz > > #+Name: foo > #+begin_src sh :var bar=bar > echo "like some result: $(echo $bar|wc -w)" > #+end_src
Accepted! ;-) Best regards, Seb PS- Woudn't it be good if we standardize the "noexport"/"no-export" thing? Have both the same (tag and property value)? -- Sebastien Vauban
