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: Wed, 12 Nov 2014 15:47:07 -0800 Message-ID: References: <87egt81acy.fsf@gmail.com> Mime-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-62033486-1415836028=:1339" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:46877) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xohfy-00044R-O2 for emacs-orgmode@gnu.org; Wed, 12 Nov 2014 18:50:21 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xohfr-000768-L3 for emacs-orgmode@gnu.org; Wed, 12 Nov 2014 18:50:14 -0500 Received: from iport-acv1-out.ucsd.edu ([132.239.0.176]:3652) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xohfr-000707-7Z for emacs-orgmode@gnu.org; Wed, 12 Nov 2014 18:50:07 -0500 In-Reply-To: <87egt81acy.fsf@gmail.com> 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: Aaron Ecay Cc: mcg , Andreas Leha , emacs-orgmode@gnu.org, Ista Zahn , Nicolas Goaziou This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-62033486-1415836028=:1339 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Wed, 12 Nov 2014, Aaron Ecay wrote: > Hi Chuck, > > 2014ko azaroak 12an, "Charles C. Berry"-ek idatzi zuen: >> >> Inline src blocks cannot update their results --- causing some of us >> heaadaches [1]. >> >> These patches fix that by placing the result of an inline src block in an >> export snippet with a faux :back-end called 'babel'. >> >> So C-c C-c with point on src_R{1+2} will insert `@@babel:3@@'. Updating >> the contents of the inline src block and retyping C-c C-c will update the >> snippet. On export, these snippets are rendered using the verbatim >> transcoder, e.g. \texttt{3} for latex backends. >> >> Support for most backends is provided. >> >> org-babel-execute-buffer will also update such snippets. > > Instead of using an export snippet, which requires per-backend changes, > you could wrap results in a macro, e.g. {{{results(2)}}}. > > Users could customize this macro per-buffer (with the usual #+macro > keyword) to provide their own formatting of inline results. You > could provide the fallback interpretation in the second call to > ‘org-macro-replace-all’ in ‘org-export-as’ (currently responsible > for expanding a few macros like {{{author}}} and {{{date}}}). > > What do you think of this idea? > Aaron, I like the flexibility that macros would allow. Some care needs to be taken with commas, but not a big deal. I don't think the usual #+MACRO works here, as the definition would be found in `org-macro-templates' by the first call and existing stuff would be expanded instead of being left for babel to remove it. But setting it up as a document keyword should work, right? Don't know if there are other gotchas. Maybe a limited collection of formats could be set up to support basic markup options and the macro could choose amongst them with a second arg set by a babel header arg. I am not quite sure how to marry this to header args. Maybe the :wrap header arg should be hijacked for inline src blocks to specify a macro for the results. I mean, does anyone actually use stuff like src_R[:wrap latex]{1+2}? The current result cannot be parsed as an export block, AFAICS. Chuck --0-62033486-1415836028=:1339--