emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Alain.Cochard@unistra.fr
To: "Fraga, Eric" <e.fraga@ucl.ac.uk>
Cc: "Alain.Cochard@unistra.fr" <Alain.Cochard@unistra.fr>,
	Org Mode List <emacs-orgmode@gnu.org>,
	Greg Minshall <minshall@umich.edu>
Subject: Re: Confused about source code blocks evaluation when exporting
Date: Thu, 14 Jul 2022 10:09:25 +0200	[thread overview]
Message-ID: <25295.53045.863530.838179@gargle.gargle.HOWL> (raw)
In-Reply-To: <87o7xsyxzr.fsf@ucl.ac.uk>

Fraga, Eric writes on Thu 14 Jul 2022 07:06:
 > On Wednesday, 13 Jul 2022 at 23:06, Alain.Cochard@unistra.fr wrote:
 > > Now I start again, but I do 'C-c C-e l o' instead.  I am _not_ asked
 > > whether I want to evaluate, and the 'foo' file is still there.  But
 > > the pdf file does display
 > >
 > > rm -f foo
 > >
 > > Does this still qualify as "evaluation"?  I thought not, hence my
 > > conclusion that evaluation was not performed by default upon export,
 > > but you made me doubt it...
 > 
 > If you do not specify either ":exports results" or ":exports both",
 > then the exporter doesn't output the results and hence there is no
 > need to evaluate the src block.

Why "there is no need"?  It was not a theoretical issue for me.
Without latexmk installed, I had to setq a different value for
org-latex-pdf-process depending on whether I used

#+cite_export: natbib plainnat

or

#+cite_export: biblatex

Sure, I can do this is in the emacs init file but then I don't how any
better than to restart emacs.  So I tried to do it on the fly with an
src block of the form

#+begin_src emacs-lisp 
(setq org-latex-pdf-process <for natib or for biblatex>)
#+end_src

which I want to be evaluated during export but I want neither the code
not its results to appear on the exported pdf file.

Maybe there are smarter ways to achieve this goal, but it was an
opportunity for me anyway to start understanding this evaluation
business.

There are other instances where this could be useful: evaluate some
shell block for deleting a file on the system before evaluating some
fortran code depending on this code.

 > The manual is indeed a bit vague about this so suggestions for
 > improvements are always welcome.

How about changing

   Org evaluates source code blocks in an Org file during export.

to

   Org generally evaluates source code blocks in an Org file during
   export.

But ideally it would be expanded, perhaps with something like
"depending on the value of some header arguments (see xxx)".

Also, how about a 'yes' option to the eval header argument to call for
unconditional evaluation?  Sorry if this would not make sense, I'm
trying...

Thank you all and best wishes.

-- 
EOST (École et Observatoire des Sciences de la Terre) 
ITE (Institut Terre & Environnement) | alain.cochard@unistra.fr
5 rue René Descartes   [bureau 106]  | Phone: +33 (0)3 68 85 50 44 
F-67084 Strasbourg Cedex, France     | [ slot available for rent ]



  reply	other threads:[~2022-07-14  8:10 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-12 12:53 Confused about source code blocks evaluation when exporting Alain.Cochard
2022-07-12 14:08 ` Fraga, Eric
2022-07-14  5:47   ` Rudolf Adamkovič
2022-07-12 14:22 ` Greg Minshall
2022-07-12 21:13 ` Alain.Cochard
2022-07-13 10:57   ` Fraga, Eric
2022-07-13 21:06     ` Alain.Cochard
2022-07-14  7:06       ` Fraga, Eric
2022-07-14  8:09         ` Alain.Cochard [this message]
2022-07-14  8:35           ` Fraga, Eric
2022-07-20 12:12             ` Alain.Cochard
2022-07-20 12:43               ` Fraga, Eric
2022-07-22  4:27                 ` Alain.Cochard
2022-07-22 17:09                   ` Fraga, Eric
2022-07-22 22:21                     ` Alain.Cochard
2022-07-14  6:06 ` Rudolf Adamkovič
2022-07-14  6:48   ` Alain.Cochard

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  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=25295.53045.863530.838179@gargle.gargle.HOWL \
    --to=alain.cochard@unistra.fr \
    --cc=e.fraga@ucl.ac.uk \
    --cc=emacs-orgmode@gnu.org \
    --cc=minshall@umich.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

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).