emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
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

  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).