From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rainer M Krug Subject: Re: [BABEL] BUG Re: Omitting try/catch blocks from tangled R code? Date: Tue, 18 Mar 2014 09:44:15 +0100 Message-ID: References: <52F498AE.6090802@krugs.de> <87siruamo3.fsf@gmail.com> <52F5326C.7010505@krugs.de> <877g7syio6.fsf@gmail.com> <87txawwwh6.fsf@gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:54463) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WPpdO-0002oE-Vo for emacs-orgmode@gnu.org; Tue, 18 Mar 2014 04:44:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WPpdJ-0006z7-NN for emacs-orgmode@gnu.org; Tue, 18 Mar 2014 04:44:30 -0400 Received: from mail-wi0-f179.google.com ([209.85.212.179]:60149) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WPpdJ-0006z2-FU for emacs-orgmode@gnu.org; Tue, 18 Mar 2014 04:44:25 -0400 Received: by mail-wi0-f179.google.com with SMTP id f8so3320974wiw.6 for ; Tue, 18 Mar 2014 01:44:24 -0700 (PDT) In-Reply-To: <87txawwwh6.fsf@gmail.com> (Eric Schulte's message of "Mon, 17 Mar 2014 11:44:53 -0600") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Eric Schulte Cc: emacs-orgmode --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable 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 w= ith a >>>>> >>> presentation I'm giving this weekend so that attendees can try th= ings >>>>> >>> 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() devic= e, >>>>> >>> and noticed that all of the tangled code where plots are generated >>>>> >>> contains the following: >>>>> >>> >>>>> >>> pdf(file=3D"file.pdf"); tryCatch({ >>>>> >>> >>>>> >>> code block contents here >>>>> >>> >>>>> >>> },error=3Dfunction(e){plot(x=3D-1:1, y=3D-1:1, type=3D'n', xlab= =3D'', ylab=3D'', >>>>> >>> axes=3DFALSE); text(x=3D0, y=3D0, labels=3De$message, col=3D'red'= ); >>>>> >>> paste('ERROR', e$message, sep=3D' : ')}); dev.off() >>>>> >>> >>>>> >>> Is there a way to omit this? >>>>> >> >>>>> >> This is a bug which must have been introduced some time ago - in t= he >>>>> >> 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 do= es (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. =20 Cheers, Rainer > > Best, > >> >> >> John >> >>> Best, >>> >>> -- >>> Eric Schulte >>> https://cs.unm.edu/~eschulte >>> PGP: 0x614CA05D =2D-=20 Rainer M. Krug email: RMKruggmailcom --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBAgAGBQJTKAdlAAoJENvXNx4PUvmCRiYIALomFyK2o8uZSrA9QkC/jJlz +LhOTdpLIT61YAJMNR7wHLu7rdAgGZO/mq5dGf92yWKdFTu/SlTUPaTIVcKKVbwA 47YGWMJjUe1pl4TQURZhRrAR8CQAnANkioovJtQvdPvw7qOao/UqNtE6ooAbysXP JdIksCS9tasJWBvhqEuh8teH7MzgQxaW49LbfGB/qw8su+1ggSH7O8wrwI2EZcV+ dfAD05txlx0Y4Pw8t0Bz4NpAQ/UHpKeqtmJFEjlYyfGLP6SctXjhFL+c0RRv0xH9 YGZYblTvzzFjDPTJ6lHJg4vnY1CZ2W1K7WlX5Ann33C8f9Ern8Zttxj9ocP3RRo= =VhSU -----END PGP SIGNATURE----- --=-=-=--