Aaron Ecay <aarone...@gmail.com> 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-into-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 ‘org-babel-exp-src-block’ which calls > ‘org-babel-exp-do-export’, which calls ‘org-babel-exp-code’. 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’re 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. -- ----------------------------------- John Kitchin http://kitchingroup.cheme.cmu.edu
