Hi Aaron, Aaron Ecay wrote: > 2013ko apirilak 18an, Sebastien Vauban-ek idatzi zuen: >> Bastien wrote: >>> I applied this patch, thanks a lot. Please see the small changes >>> I made to the ChangeLog entry for next commit messages: >>> >>> http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=25869e >> >> How is that suppose to cooperate with ":eval never-export" (which avoids all >> the evaluations during export)? > > I could be wrong, but I don’t seem to see a convenient way to set this > header arg for both inline source blocks and #+call lines. These both > have no way of storing their results in a buffer, so in order to have > them be present in the export they must be evaluated every time. > > On the other hand, it is not always desirable to call code blocks on > every export. They could be very time-consuming to compute. So, a way > to pick out the non-results-storing blocks is needed. > >> I'm not sure to understand why this change is implemented as a variable which >> we would have to set up in our .emacs or bind in the file, instead of an >> header argument which we could set wherever we want (system-wide, >> language-specific, buffer-wide, subtree-wide, or code >> block-specific)... > > What form would this take? Would we have a value of :eval which is > never-export-unless-inline?
As we're talking of evaluation, and as there is already an ":eval" header argument (with lots of options), I think it'd better to try to add your requirement as a new option, yes, instead of having complex rules for knowing what happens depending on every option of ":eval" times 2 (with or without your new value). I'm not sure what ":eval never-export" currently does with inline blocks, but (depending on that) I'd rather add the new value "never-export-except-inline" (or "never-export-nor-inline"). Note -- The option names are not correct, just to carry what I mean... That way, you can impose your new behavior wherever you want, as well in parts of your Org document. Best regards, Seb -- Sebastien Vauban