From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Sebastien Vauban" Subject: Re: [PATCH] Add 'inline-only option to org-export-babel-evaluate Date: Thu, 18 Apr 2013 12:19:50 +0200 Message-ID: <86ppxsjg3d.fsf@somewhere.org> References: <1364795085-14578-1-git-send-email-aaronecay@gmail.com> <87bo9wr33z.fsf@gmail.com> <874nf4s0ut.fsf@gmail.com> <87ip3k8bzf.fsf@bzg.ath.cx> <86sj2okxfk.fsf@somewhere.org> <87vc7kqio4.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org-mXXj517/zsQ@public.gmane.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org-mXXj517/zsQ@public.gmane.org To: emacs-orgmode-mXXj517/zsQ@public.gmane.org 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: >>>=20 >>> http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=3D25869e >>=20 >> How is that suppose to cooperate with ":eval never-export" (which avoids= all >> the evaluations during export)? > > I could be wrong, but I don=E2=80=99t 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 knowi= ng 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, b= ut (depending on that) I'd rather add the new value "never-export-except-inlin= e" (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 pa= rts of your Org document. Best regards, Seb --=20 Sebastien Vauban