From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aaron Ecay Subject: Re: New patches WAS Re: [PATCH] inline src block results can be removed Date: Sun, 18 Jan 2015 14:13:01 -0500 Message-ID: <87k30jj41u.fsf@gmail.com> References: <87egt81acy.fsf@gmail.com> <8761ejq9ek.fsf@nicolasgoaziou.fr> <87sihltt3v.fsf@selenimh.mobile.lan> <87zjbqrapy.fsf@nicolasgoaziou.fr> <874mrqjdlw.fsf@gmail.com> <87wq4lqcbh.fsf@nicolasgoaziou.fr> 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]:54404) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YCvHX-0000SH-0Z for emacs-orgmode@gnu.org; Sun, 18 Jan 2015 14:13:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YCvHT-0005UF-QS for emacs-orgmode@gnu.org; Sun, 18 Jan 2015 14:13:06 -0500 Received: from mail-qc0-x233.google.com ([2607:f8b0:400d:c01::233]:35333) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YCvHT-0005SI-Lu for emacs-orgmode@gnu.org; Sun, 18 Jan 2015 14:13:03 -0500 Received: by mail-qc0-f179.google.com with SMTP id w7so3116421qcr.10 for ; Sun, 18 Jan 2015 11:13:02 -0800 (PST) In-Reply-To: <87wq4lqcbh.fsf@nicolasgoaziou.fr> 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 Nicolas, 2015ko urtarrilak 17an, Nicolas Goaziou-ek idatzi zuen: > It would be more flexible, but it would also defeat the whole point of > the "results" macro, that is to be able to mark /unambiguously/ the > output of an inline block. Indeed, even if you can get the name of the > macro from the parameter, you cannot be sure the macro was generated by > the code block, unlike to a results macro. Well, you could examine the code block=E2=80=99s :wrap header arg to determ= ine what kind of macro it generates, rather than hardcoding =E2=80=9Cresults.= =E2=80=9D (This would break when :wrap=E2=80=99s value was changed, though). Probably a better solution is that the results macro could wrap the custom macro: {{{results({{{mymacro(foo)}}})}}} >=20 > Also, I don't think we really need this flexibility since any twist to > the output can be made at the Babel level, or even using > `org-babel-inline-result-wrap'. o-b-inline-result-wrap can=E2=80=99t be specified on a per-block basis like header args can. And doing it within babel would lead to extra verbosity. As an example use case, I sometimes write things like: src_R{round(100*78/7065,2)} What I=E2=80=99m really interested in is the value 100*78/7065,=C2=B9 but I= don=E2=80=99t want it spilling its many decimal places into the exported document (I don=E2=80= =99t particularly mind them in the org file). I think the following would be a better way of writing things like this, since it separates the presentation (round to two decimal places) from the content (100*78/7065): src_R[:wrap round2]{100*78/7065} I would write a round2 macro to arrange the rounding. (round2 and round0/truncate would probably cover 90+% of my use of inline R blocks). For latex, this would use one of the packages like siunitx or pgfplots which offer number formatting (including other fancy options like scientific notation for large numbers). For other backends, I=E2=80=99d probably use an eval-type macro to do the rounding in elisp. =C2=B9 This is just a particularly simple example; often the value is not just the result of some arithmetic, but rather a coefficient extracted from a statistical model by a series of function calls etc. Thanks, --=20 Aaron Ecay