From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andreas Leha Subject: Re: [PATCH] inline src block results can be removed Date: Thu, 13 Nov 2014 19:06:33 +0000 Message-ID: References: <87egt81acy.fsf@gmail.com> <8761ejq9ek.fsf@nicolasgoaziou.fr> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:38476) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xozj2-00009d-SF for emacs-orgmode@gnu.org; Thu, 13 Nov 2014 14:06:42 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xozix-0004Xl-Gr for emacs-orgmode@gnu.org; Thu, 13 Nov 2014 14:06:36 -0500 Received: from plane.gmane.org ([80.91.229.3]:33996) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xozix-0004XG-Aj for emacs-orgmode@gnu.org; Thu, 13 Nov 2014 14:06:31 -0500 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Xozit-0002c8-Gq for emacs-orgmode@gnu.org; Thu, 13 Nov 2014 20:06:27 +0100 Received: from cpc33-cmbg15-2-0-cust4.5-4.cable.virginm.net ([81.102.136.5]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 13 Nov 2014 20:06:27 +0100 Received: from andreas.leha by cpc33-cmbg15-2-0-cust4.5-4.cable.virginm.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 13 Nov 2014 20:06:27 +0100 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: emacs-orgmode@gnu.org Hi, Nicolas Goaziou writes: > Hello, > > "Charles C. Berry" writes: > >> I like the flexibility that macros would allow. > > I like it too. Macros are much better than export snippets for the task. > >> 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 think {{{results()}}} should remain a dumb wrapper itself and not try > to do some formatting (i.e., a simple, hard-coded macro). Formatting > should be on the side of Babel and, possibly, its arguments. Let's not > duplicate features. > >> 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. > > Macro can be the default output. If you don't want a macro, use raw > header. IOW, there is no need for a specific header arg. > >> 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. > > It could evaluate to @@latex:3@@. Parsing can also be solved if > necessary. > Without too much value to add to this thread at this point, I just want to say, that I love the direction this thread has taken. There is good reason now to hope for better inline results handling in org. > Thanks for your work. I second that! Thanks, Chuck! Regards, Andreas