From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Charles C. Berry" Subject: Re: [PATCH] inline src block results can be removed Date: Tue, 11 Nov 2014 22:58:11 -0800 Message-ID: References: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:35010) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XoRsk-0006IP-G2 for emacs-orgmode@gnu.org; Wed, 12 Nov 2014 01:58:29 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XoRsd-00029B-Kc for emacs-orgmode@gnu.org; Wed, 12 Nov 2014 01:58:22 -0500 Received: from iport-acv2-out.ucsd.edu ([132.239.0.174]:36456) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XoRsd-000294-7Y for emacs-orgmode@gnu.org; Wed, 12 Nov 2014 01:58:15 -0500 In-Reply-To: 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: Andreas Leha Cc: emacs-orgmode@gnu.org On Wed, 12 Nov 2014, Andreas Leha wrote: > Hi Chuck, > > "Charles C. Berry" 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