From: John Hendy <jw.hendy@gmail.com>
To: Eric Schulte <schulte.eric@gmail.com>
Cc: Rainer@krugs.de, emacs-orgmode <emacs-orgmode@gnu.org>
Subject: Re: [BABEL] BUG Re: Omitting try/catch blocks from tangled R code?
Date: Mon, 17 Mar 2014 12:11:20 -0500 [thread overview]
Message-ID: <CA+M2ft8Rz-jXPV2qb3sRQv2s-236tO7rVV8g__c5ZQuKrBcq4w@mail.gmail.com> (raw)
In-Reply-To: <877g7syio6.fsf@gmail.com>
On Mon, Mar 17, 2014 at 10:00 AM, Eric Schulte <schulte.eric@gmail.com> wrote:
> John Hendy <jw.hendy@gmail.com> writes:
>
>> On Fri, Feb 7, 2014 at 1:22 PM, Rainer M Krug <Rainer@krugs.de> wrote:
>>>
>>>
>>>
>>> On 02/07/14, 17:47 , Eric Schulte wrote:
>>> > Rainer M Krug <Rainer@krugs.de> writes:
>>> >
>>> >> On 02/07/14, 07:18 , John Hendy wrote:
>>> >>> Greetings,
>>> >>>
>>> >>>
>>> >>> I don't usually tangle, but am creating a code file to go along with a
>>> >>> presentation I'm giving this weekend so that attendees can try things
>>> >>> out afterward by cloning my github repo where all the data and
>>> >>> necessary files are stored.
>>> >>>
>>> >>> In my presentation (Beamer), I create plots via the R pdf() device,
>>> >>> and noticed that all of the tangled code where plots are generated
>>> >>> contains the following:
>>> >>>
>>> >>> pdf(file="file.pdf"); tryCatch({
>>> >>>
>>> >>> code block contents here
>>> >>>
>>> >>> },error=function(e){plot(x=-1:1, y=-1:1, type='n', xlab='', ylab='',
>>> >>> axes=FALSE); text(x=0, y=0, labels=e$message, col='red');
>>> >>> paste('ERROR', e$message, sep=' : ')}); dev.off()
>>> >>>
>>> >>> Is there a way to omit this?
>>> >>
>>> >> This is a bug which must have been introduced some time ago - in the
>>> >> stock version of emacs (Org-mode version 7.9.3f
>>> >> (release_7.9.3f-17-g7524ef @
>>> >> /usr/local/Cellar/emacs/24.3/share/emacs/24.3/lisp/org/)) it does not
>>> >> tangle the enclosing commands to create graphics, but in 8.2 it does (I
>>> >> don't have an older version at hand to go further back).
>>> >>
>>> >
>>> > I believe this was introduced by your commit eaa3a761d. Reversion of
>>> > which with the following should provide a temporary workaround.
>>>
>
> I take this back, the behavior is unrelated to Rainer's commit adding
> try/catch blocks to R graphics creation logic.
>
> In fact I don't believe this is a bug, rather the default behavior is to
> expand code block bodies on tangling. This behavior may be changed by
> using the :no-expand header argument which will inhibit code block body
> expansion during tangling.
>
Got it, and thanks for the new variable tip!
Out of curiosity, is there a consensus that this is the preferred
behavior for tangling by default? I'm guessing at some point it was
decided that the need was preferred to have these bits inserted
before/after code blocks, but just trying to confirm this. It seems
odd to me, at least given R's behavior, that someone would prefer
these bits to show up in the tangled file since they appeared to serve
the purpose of having Org not fail during export vs. benefitting the
code in any way (if I wasn't running code through R, I'd just get the
errors directly).
John
> Best,
>
> --
> Eric Schulte
> https://cs.unm.edu/~eschulte
> PGP: 0x614CA05D
next prev parent reply other threads:[~2014-03-17 17:11 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-07 6:18 Omitting try/catch blocks from tangled R code? John Hendy
2014-02-07 8:26 ` [BABEL] BUG " Rainer M Krug
2014-02-07 16:47 ` Eric Schulte
2014-02-07 19:22 ` Rainer M Krug
2014-03-12 1:13 ` John Hendy
2014-03-17 15:00 ` Eric Schulte
2014-03-17 17:11 ` John Hendy [this message]
2014-03-17 17:44 ` Eric Schulte
2014-03-18 8:44 ` Rainer M Krug
2014-03-18 21:56 ` John Hendy
2014-03-19 19:07 ` Charles Berry
2014-03-20 4:57 ` Eric Schulte
2014-03-20 9:22 ` Rainer M Krug
2014-03-24 2:03 ` Eric Schulte
2014-03-24 10:22 ` Rainer M Krug
2014-03-24 13:16 ` Eric Schulte
2014-03-25 9:37 ` Rainer M Krug
2014-03-26 20:17 ` Eric Schulte
2014-03-28 8:32 ` Rainer M Krug
2014-03-28 8:51 ` Rainer M Krug
2014-03-30 14:19 ` Eric Schulte
2014-03-31 7:52 ` Rainer M Krug
2014-04-02 23:09 ` Eric Schulte
2014-04-07 7:59 ` Rainer M Krug
2014-04-11 2:35 ` Eric Schulte
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CA+M2ft8Rz-jXPV2qb3sRQv2s-236tO7rVV8g__c5ZQuKrBcq4w@mail.gmail.com \
--to=jw.hendy@gmail.com \
--cc=Rainer@krugs.de \
--cc=emacs-orgmode@gnu.org \
--cc=schulte.eric@gmail.com \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.