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

[Rainer M Krug]

Eric Schulte <address@hidden> writes:

> Charles Berry <address@hidden> 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?

Makes perfect sense to me, and would definitely be the better place to
add them.

If one wants enclosing code in the tangling, there is always
the :epilogue and :prologue header arguments, and the try/catch should
be considered as internal to the execution.

Rainer

>
>>
>> Best,
>>
>> Chuck
>>
>>

-- 
Rainer M. Krug
email: Rainer<at>krugs<dot>de
PGP: 0x0F52F982

pgpgUIpFLOZ7s.pgp
Description: PGP signature