Rainer M Krug writes: > Eric Schulte writes: > >> Charles Berry writes: >> >>> John Hendy 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. > Great, how's this patch work? If it looks good I'll apply it. Thanks,