From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aaron Ecay Subject: Re: [PATCH] inline src block results can be removed Date: Fri, 14 Nov 2014 23:04:06 +0000 Message-ID: <877fyx1j15.fsf@gmail.com> References: <87egt81acy.fsf@gmail.com> <8761ejq9ek.fsf@nicolasgoaziou.fr> <87sihltt3v.fsf@selenimh.mobile.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:33438) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XpPuc-0001nP-Rb for emacs-orgmode@gnu.org; Fri, 14 Nov 2014 18:04:24 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XpPuX-0005hs-57 for emacs-orgmode@gnu.org; Fri, 14 Nov 2014 18:04:18 -0500 Received: from mail-wi0-x235.google.com ([2a00:1450:400c:c05::235]:34022) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XpPuW-0005hg-P8 for emacs-orgmode@gnu.org; Fri, 14 Nov 2014 18:04:13 -0500 Received: by mail-wi0-f181.google.com with SMTP id n3so4180103wiv.2 for ; Fri, 14 Nov 2014 15:04:11 -0800 (PST) In-Reply-To: <87sihltt3v.fsf@selenimh.mobile.lan> 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: Nicolas Goaziou , "Charles C. Berry" Cc: mcg , Andreas Leha , emacs-orgmode@gnu.org, Ista Zahn Hi Chuck, Hi Nicolas, I had a response to Chuck=E2=80=99s earlier message that was sitting around waiting to be finished...time marches on however. Apologies. I think the following bit is the only part that=E2=80=99s potentially still relevan= t: >=20 > I don't think the usual #+MACRO works here, as the definition would be=20 > found in `org-macro-templates' by the first call and existing stuff would= =20 > be expanded instead of being left for babel to remove it.=20 I see what you mean. One option might be to do the following in org-export-as (untested pseudocode): (org-macro-initialize-templates) (let (results-macro) (setq results-macro (assoc "results" org-macro-templates)) (setq org-macro-templates (remove results-macro org-macro-templates)) (org-macro-replace-all org-macro-templates) (org-export-execute-babel-code) (org-macro-replace-all (list (or results-macro (cons "results" org-default-result-macro) ;; new d= efcustom or defvar )))) Back to the present: 2014ko azaroak 14an, Nicolas Goaziou-ek idatzi zuen: >=20 > "Charles C. Berry" writes: >=20 >> More patches (as you can see). Now ox.el, ob-core.el, and ob-exp.el >> are patched. >=20 > Thanks. >=20 >> Also, the user can customize org-babel-inline-result-wrap to always >> get verbatim or otherwise wrap the contents of the macro. >=20 > I don't think this is a good idea. >=20 > If we rely on the macro recognition to properly inline results, setting > to anything else would break Org. It should be a defconst or we are > bound to shoot ourselves in the foot. >=20 > If a user wants verbatim output, he will have to somehow generate > {{{results:=3Doutput=3D}}}, e.g., through appropriate code or parameters. This is a step back from the present situation, where a user can get a custom format applied by default to all inline results by setting =E2=80=98org-babel-inline-result-wrap=E2=80=99. I think it=E2=80=99s reaso= nable for users to want to set off babel results in a special font (to indicate that they are automatically generated, e.g.) This proposal would add an additional overhead for generating this formatting to every inline call. I think the method I sketched above will allow users to redefine the results macro in the same way as any other macro (via #+MACRO), thus allowing the possibility of user-specified special formatting. [...] >> * lisp/ob-core.el (org-babel-inline-result-wrap): Default is >> "{{{results(%s)}}}". >=20 > As written earlier, I highly suggest to make it a defconst. Indeed, this seems correct. (The =E2=80=9Cconst=E2=80=9D designation is ju= st a hint to users/developers =E2=80=93 it doesn=E2=80=99t affect the ability of people = who really want to customize the value to setq it to something else in their init file.) > With {{{results(@@backend:...@@)}}}, we don't need the extra trick. Even > if it is more verbose, I think a regular syntax is better. This doesn=E2=80=99t mesh with the suggestion to allow the results macro to supply formatting. --=20 Aaron Ecay