From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Kitchin Subject: Re: update on missing :parameters in code blocks Date: Mon, 22 Sep 2014 12:40:41 -0400 Message-ID: References: <8738bkqsyj.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:56475) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XW6fX-0003Uc-AB for emacs-orgmode@gnu.org; Mon, 22 Sep 2014 12:41:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XW6fR-0001yW-K5 for emacs-orgmode@gnu.org; Mon, 22 Sep 2014 12:40:55 -0400 Received: from mail-qc0-x234.google.com ([2607:f8b0:400d:c01::234]:49469) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XW6fR-0001wd-GE for emacs-orgmode@gnu.org; Mon, 22 Sep 2014 12:40:49 -0400 Received: by mail-qc0-f180.google.com with SMTP id r5so373775qcx.11 for ; Mon, 22 Sep 2014 09:40:44 -0700 (PDT) Received: from Johns-MacBook-Air.local (KITCHIN-TIMEMACHINE.CHEME.CMU.EDU. [128.2.54.215]) by mx.google.com with ESMTPSA id 36sm8155662qgn.10.2014.09.22.09.40.42 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Sep 2014 09:40:43 -0700 (PDT) In-Reply-To: <8738bkqsyj.fsf@gmail.com> (Aaron Ecay's message of "Sun, 21 Sep 2014 22:39:32 -0400") 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: emacs-orgmode@gnu.org Aaron Ecay writes: Thanks for the confirmation this happens, and the pointer to where it happens. I guess there was at one point a good reason to do this, but I cannot see it directly. I found a way to do it with filters and preprocessing, which is illustrated here: http://kitchingroup.cheme.cmu.edu/blog/2014/09/22/Showing-what-data-went-in= to-a-code-block-on-export/ It works, but I feel like it is a workaround that should not be needed. It does look like some effort to change this, and first it would be good to know why the modification is being done. Thanks again for the hints. > Hi John, > > Look at the functions =E2=80=98org-babel-exp-src-block=E2=80=99 which cal= ls > =E2=80=98org-babel-exp-do-export=E2=80=99, which calls =E2=80=98org-babel= -exp-code=E2=80=99. The tl;dr > version is that indeed the babel export machinery does change the code > block in substantial ways, including the removal of parts of it. > > This plays merry hell with the cache mechanism, as you might imagine > (different header args at different points -> the sha1 hash changes). A > year or more ago I worked on a patch to overhaul this system. I got > partway through before giving up, because it turned into a massive > undertaking and because it became clear that the cache mechanism would > not be very reliable/useful for my needs anyway. But IMHO it remains an > imperfection in the interface between babel and the new parser, and it > might be possible to avoid the necessity of doing this sort of > destructive modification during export. Along the way simplification of > the code might also be possible. > > Let me know if you=E2=80=99re interested; I may be able to dig the old > half-patch out of a disused git branch somewhere. It may have bitrotted > some, but it may also be useful. --=20 ----------------------------------- John Kitchin http://kitchingroup.cheme.cmu.edu