emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Rainer M Krug <Rainer@krugs.de>
To: Eric Schulte <schulte.eric@gmail.com>
Cc: emacs-orgmode <emacs-orgmode@gnu.org>
Subject: Re: [BABEL] BUG Re: Omitting try/catch blocks from tangled R code?
Date: Tue, 18 Mar 2014 09:44:15 +0100	[thread overview]
Message-ID: <m2ob13rj4w.fsf@krugs.de> (raw)
In-Reply-To: <87txawwwh6.fsf@gmail.com> (Eric Schulte's message of "Mon, 17 Mar 2014 11:44:53 -0600")

[-- Attachment #1: Type: text/plain, Size: 4253 bytes --]

Eric Schulte <schulte.eric@gmail.com> writes:

> John Hendy <jw.hendy@gmail.com> writes:
>
>> 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?
>
> There may have been a consensus in a single thread motivated by a single
> use case, which should not necessarily be a global consensus.
>
>> 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).
>>
>
> I'd be happy to add :no-expand to the default R header arguments.  Or
> even to change this behavior globally, if the current behavior is
> universally surprising.

I think the default behavior should be reverted, as tangling and
exporting are two different things. When I tangle, I want to see the
code blocks as they are in the org document (with possible variables and
expansions) but not to create files where I do not put it explicitly
into a code block. These wrappers have nothing to do with the code, and
are only there for the exported engine. So I would either revert to the
original behavior, or, introduce a new header argument,
e.g. :include-wrappers, which would, if set to t, include the export
wrappers in the tangled file. This might be useful for debugging
exporting of code block results, but not for general tangling.
 
Cheers,

Rainer

>
> Best,
>
>>
>>
>> John
>>
>>> Best,
>>>
>>> --
>>> Eric Schulte
>>> https://cs.unm.edu/~eschulte
>>> PGP: 0x614CA05D

-- 
Rainer M. Krug

email: RMKrug<at>gmail<dot>com

[-- Attachment #2: Type: application/pgp-signature, Size: 494 bytes --]

  reply	other threads:[~2014-03-18  8:44 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
2014-03-17 17:44             ` Eric Schulte
2014-03-18  8:44               ` Rainer M Krug [this message]
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

  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=m2ob13rj4w.fsf@krugs.de \
    --to=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 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).