On Wed, 12 Nov 2014, Andreas Leha wrote:
Hi Chuck,
"Charles C. Berry" <ccbe...@ucsd.edu> writes:
Inline src blocks cannot update their results --- causing some of us
heaadaches [1].
[deleted announcement of fix]
First of all: Thanks a lot! I'll (try to find time to) test these
patches.
Yes. Please try them.
Reading your description, I already have a first further feature
request, though ;-) Or rather a question.
It sounds as if your patches turn inline source into limited source
blocks in terms of adherence to header arguments. Given that most
likely there are not too many header arguments on inline source blocks,
this might not be a huge problem.
See below ":results latex" and friends seem to work as before.
It would be nice if others could point out any hiccups.
But my first question would be about ':results raw', as I never had a
case where I wanted the results of my inline source block to be
\texttt{}.
If you start with src_R{1+2} and evaluate it, you get the `@@babel:3@@'.
If you modify that to src_R[:results raw]{1+2} and evaluate it, the
`@@...@@' goes away and is replaced with the raw result `3'. Of course,
you are then stuck with that and cannot easily make further revisions.
However, with modest tooling, you can set up the :results header
bufferwide so that when you want to export, the '@@...@@' will be removed
from the temp buffer and the export will use `raw' results for inline src
blocks.
Or you can make a custom version of org-latex-export-snippet that uses a
different transcoder. Or you can just return the raw text and the
`@@babel:3@@' will end up in the *.tex as 3. Just change the last line to
(org-element-property :value export-snippet)[more parens] to get the raw
value all the time.
I guess, my question is: Do your patches restrict the use of babel
headers on inline source blocks. And if so, is that just a matter of
'not implemented yet' or is there a fundamental issue here?
I do not think things are worse with the patches.
src_R[:results latex]{1+2} is the same with the patches, I think. But
ideally, that would generate something that acts like @@latex:3@@ and that
could be safely removed.
In terms of implementation, if one wanted fine control over each inline
src block, more tooling will be needed. Export snippets do not have lots
of stops and whistles to play with, just a :back-end and a :value and
location info. One could use `org-export-get-previous-element' to look up
the header args and figure out what to do next. But that can get hairy if
the header arg needs further processing. Considering the limited use to
which inline src blocks are put, it probably is not coding up loads of
tricky features.
Best,
Chuck
