Eric Schulte writes: > John Hendy writes: > >> On Mon, Mar 17, 2014 at 10:00 AM, Eric Schulte wrote: >>> John Hendy writes: >>> >>>> On Fri, Feb 7, 2014 at 1:22 PM, Rainer M Krug wrote: >>>>> >>>>> >>>>> >>>>> On 02/07/14, 17:47 , Eric Schulte wrote: >>>>> > Rainer M Krug 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: RMKruggmailcom