From: "Charles C. Berry" <ccberry@ucsd.edu>
To: Andreas Leha <andreas.leha@med.uni-goettingen.de>
Cc: emacs-orgmode@gnu.org
Subject: Re: [PATCH] inline src block results can be removed
Date: Tue, 11 Nov 2014 22:58:11 -0800 [thread overview]
Message-ID: <alpine.OSX.2.00.1411112149220.8006@charles-berrys-macbook.local> (raw)
In-Reply-To: <olu4mu5dy0f.fsf@med.uni-goettingen.de>
On Wed, 12 Nov 2014, Andreas Leha wrote:
> Hi Chuck,
>
> "Charles C. Berry" <ccberry@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
next prev parent reply other threads:[~2014-11-12 6:58 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-12 0:49 [PATCH] inline src block results can be removed Charles C. Berry
2014-11-12 1:10 ` Andreas Leha
2014-11-12 6:58 ` Charles C. Berry [this message]
2014-11-12 19:34 ` Aaron Ecay
2014-11-12 23:47 ` Charles C. Berry
2014-11-13 17:48 ` Nicolas Goaziou
2014-11-13 19:06 ` Andreas Leha
2014-11-14 17:43 ` Charles C. Berry
2014-11-14 20:39 ` Nicolas Goaziou
2014-11-14 23:04 ` Aaron Ecay
2014-11-16 0:10 ` Nicolas Goaziou
2014-11-15 20:22 ` Charles C. Berry
2014-11-16 23:23 ` Nicolas Goaziou
2014-11-24 9:48 ` Daniele Pizzolli
2014-11-24 10:18 ` Andreas Leha
2015-01-13 0:48 ` New patches WAS " Charles C. Berry
2015-01-16 22:41 ` Nicolas Goaziou
2015-01-19 3:22 ` Charles C. Berry
2015-01-19 17:53 ` Nicolas Goaziou
2015-01-19 19:31 ` Charles C. Berry
2015-01-20 23:30 ` Nicolas Goaziou
2015-01-22 3:07 ` Charles C. Berry
2015-01-22 23:08 ` Nicolas Goaziou
2015-01-24 22:47 ` Charles C. Berry
2015-01-25 1:14 ` Aaron Ecay
2015-01-25 5:01 ` Charles C. Berry
2015-01-29 20:31 ` Charles C. Berry
2015-01-17 3:22 ` Aaron Ecay
2015-01-17 22:20 ` Nicolas Goaziou
2015-01-18 19:13 ` Aaron Ecay
2015-01-18 22:34 ` Nicolas Goaziou
2015-01-18 22:55 ` Aaron Ecay
-- strict thread matches above, loose matches on Subject: below --
2014-11-24 11:12 Daniele Pizzolli
2014-11-25 8:04 ` Daniele Pizzolli
2014-11-25 9:52 ` Andreas Leha
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.OSX.2.00.1411112149220.8006@charles-berrys-macbook.local \
--to=ccberry@ucsd.edu \
--cc=andreas.leha@med.uni-goettingen.de \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).