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: Sat, 15 Nov 2014 12:22:22 -0800 Message-ID: References: <87egt81acy.fsf@gmail.com> <8761ejq9ek.fsf@nicolasgoaziou.fr> <87sihltt3v.fsf@selenimh.mobile.lan> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:54653) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xpjrd-0005zb-Ah for emacs-orgmode@gnu.org; Sat, 15 Nov 2014 15:22:40 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XpjrW-0006iO-FQ for emacs-orgmode@gnu.org; Sat, 15 Nov 2014 15:22:33 -0500 Received: from iport-acv1-out.ucsd.edu ([132.239.0.176]:62663) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XpjrW-0006iI-34 for emacs-orgmode@gnu.org; Sat, 15 Nov 2014 15:22:26 -0500 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 Cc: Aaron Ecay , Andreas Leha , emacs-orgmode@gnu.org, Ista Zahn , mcg On Fri, 14 Nov 2014, Nicolas Goaziou wrote: > "Charles C. Berry" writes: > >> More patches (as you can see). Now ox.el, ob-core.el, and ob-exp.el >> are patched. > > Thanks. > [skipping to the bottom - omitting useful critiques of code and opinions about strategy and tactics from Nicolas] > WDYT? After staring at `org-babel-insert-result' for too long, I am beginning to feel like Alice in Wonderland. As currently implemented, inline src blocks are somewhere between fragile and broken. I worry about making them even more fragile, the logic in `org-babel-insert-result' has plenty of twists ans turns, and I cannot commit the effort to dig deeply into them. So I am looking for an easy way out. For now, I'd be willing to make patches that will allow removal of the inline src block results that do *not* involve these header args: - :file - :wrap - :results latex html drawer org code which I can do barely touching `org-babel-insert-result' and this simplifies matters a lot. I propose to do this by using the patches of ox.el and ob-exp.el from my last post. For ob-core.el, I would - leave defcustom org-babel-inline-wrap as "=%s=" (or use defconst - I do not have a strong opinion either way). - allow replacement of exising results in `org-babel-insert-result' like so #+BEGIN_EXAMPLE - (existing-result (unless inlinep -(org-babel-where-is-src-block-result + (existing-result (if inlinep +(org-babel-delete-results-macro) + (org-babel-where-is-src-block-result #+END_EXAMPLE and defun `org-babel-delete-results-macro' per Nicolas' suggestions for `org-babel-delete-babel-snippet' (from earlier patch) to use `org-element-context' and friends (and not mess with export snippets). - modify `org-babel-examplify-region' along these lines #+BEGIN_SRC emacs-lisp (insert (replace-regexp-in-string "," "\\," (format (concat "{{{results(" org-babel-inline-result-wrap ")}}}" (prog1 (buffer-substring beg end) (delete-region beg end)))) nil t)) #+END_SRC I believe that this is simple enough to avoid breaking idioms that folks might use now. As for the choice between "=%s=" and "%s", the latter was hard coded until f285b7ed3d097dd1cbb55fa3c31bc92aa0149054 in February 2013 and has been the default since. It also parallels what happens with handling src block results. Going forward I do not think this behavior should change. I have too litle experience with #+MACROs to know if Aaron's suggestion to let the user customize the macro is opening up potential issues when users get `creative'. I can do what I've outlined in the coming days. If it is felt that more retooling of `org-babel-insert-results' is really needed, I can get to it early next year. In fact, I'll be out of email range from late this month till then, so any problems I create now will have to wait till then for me to work on them. Thanks for the critique of my earlier patches and your thoughts. Best, Chuck