emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: "Sebastien Vauban" <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org>
To: emacs-orgmode-mXXj517/zsQ@public.gmane.org
Subject: Re: [PATCH] Add 'inline-only option to org-export-babel-evaluate
Date: Thu, 18 Apr 2013 12:19:50 +0200	[thread overview]
Message-ID: <86ppxsjg3d.fsf@somewhere.org> (raw)
In-Reply-To: <87vc7kqio4.fsf@gmail.com>

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,

Sebastien Vauban

      reply	other threads:[~2013-04-18 10:19 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-01  5:44 Aaron Ecay
2013-04-01  7:45 ` Nicolas Goaziou
2013-04-01 15:10   ` Aaron Ecay
2013-04-02 22:14 ` Eric Schulte
2013-04-18  8:24   ` Aaron Ecay
2013-04-18  8:44     ` Bastien
2013-04-18  9:19       ` Sebastien Vauban
2013-04-18  9:42         ` Aaron Ecay
2013-04-18 10:19           ` Sebastien Vauban [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86ppxsjg3d.fsf@somewhere.org \
    --to=wxhgmqzgwmuf-genee64ty+gs+fvcfc7uqw@public.gmane.org \
    --cc=emacs-orgmode-mXXj517/zsQ@public.gmane.org \
    --subject='Re: [PATCH] Add '\''inline-only option to org-export-babel-evaluate' \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Code repositories for project(s) associated with this inbox:


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).