Re: [BABEL] BUG Re: Omitting try/catch blocks from tangled R code?

[Eric Schulte <schulte.eric@gmail.com>]

Charles Berry <ccberry@ucsd.edu> writes:

> John Hendy <jw.hendy <at> gmail.com> writes:
>
> [deleted]
>> >
>> > 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.
>> 
>> Thanks for chiming in. This was my gut reaction to the default
>> behavior. I guess we're still only a sample size of 2, but
>> intuitively, I would think that tangling would be a separate beast in
>> most cases from exporting. Just to have it on the record, if I tangle,
>> it's usually to take the code I've used in something like a Beamer
>> presentation or document and combine it into a single .R file so
>> someone can run it without needing Org-mode.
>
> [deleted]
>
> Sorry to be late to add my $0.02...
>
> I never want the try/catch wrappers.
>
> But noweb is indispensable.
>
> I use noweb a lot to organize and collect blocks. In some cases, I export
> them and in others I just tangle them.
>
> I hope that the revised code will allow me to turn off try/catch wrapping
> and still be able to use noweb when tangling or exporting.
>

In addition to noweb, there are cases where variable expansion is useful
in tangled code.

The simplest option is to move things like try/catch blocks out of the
code block expansion function, and into the execution function.  Then if
other language present similar constructs (which we want to add to
execution by default but never want to tangle), we can think about
abstracting this out into some new level of code block expansion.

Thoughts?

>
> Best,
>
> Chuck
>
>

-- 
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D