From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Charles C. Berry" Subject: Re: New patches WAS Re: [PATCH] inline src block results can be removed Date: Mon, 19 Jan 2015 11:31:26 -0800 Message-ID: References: <87egt81acy.fsf@gmail.com> <8761ejq9ek.fsf@nicolasgoaziou.fr> <87sihltt3v.fsf@selenimh.mobile.lan> <87zjbqrapy.fsf@nicolasgoaziou.fr> <87lhl2s5zc.fsf@nicolasgoaziou.fr> <87oapuac7g.fsf@nicolasgoaziou.fr> 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]:50299) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YDI2v-0004CR-UK for emacs-orgmode@gnu.org; Mon, 19 Jan 2015 14:31:34 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YDI2s-00069q-MI for emacs-orgmode@gnu.org; Mon, 19 Jan 2015 14:31:33 -0500 Received: from iport-acv2-out.ucsd.edu ([132.239.0.174]:29112) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YDI2s-00069V-7U for emacs-orgmode@gnu.org; Mon, 19 Jan 2015 14:31:30 -0500 In-Reply-To: <87oapuac7g.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 Cc: Aaron Ecay , Andreas Leha , emacs-orgmode@gnu.org, Ista Zahn , mcg On Mon, 19 Jan 2015, Nicolas Goaziou wrote: > "Charles C. Berry" writes: > > Thanks for the patches. Here's another round of comments. > >> OK. Now those cases (and some others) insert `*Inline error:' and a >> comment as to what the error is and ignore the actual value. >> >> Based on my own experience, I thought it best to allow Babel to run >> without stopping when there are problems with inline src blocks rather >> than stop with an error. > > We already stop with an error for missing footnotes definitions or > missing macro templates. I'm not totally against your suggestion, but > I think it would be better to follow this. > OK. I'll try it. If there are howls of pain from users (including my own howls), it will be easy enough to fix. >> I hope the approach I took modifies `org-macro-expand'. >> >> The "as-is" template returns the macro element :value stripped of the >> leading "{{{(" and the trailing "[\n]?)}}}". The template >> allows macros that mark text - possibly including commas - but do not >> modify it. > > Actually I preferred the previous implementation because this one adds > another level of indirection, the (undocumented) "as-is" template. > "results" -> "$1" was more elegant. > > We just need an `org-macro-protect-argument' function. I can do the > refactoring if you want. > This is probably the shortest path. I'd apprecaite it if you would refactor that part. >> I am not sure why you mentioned org-element.el. > > The snippet you were using comes from `org-element-macro-parser', in > "org-element.el". If two locations use the same snippet, it is better to > refactor it. > This is where I get mixed up. I'm not sure exactly what the refactoring amounts to. So I guess I need to see what the refactoring amounts to, then deal with the rest of your comments. Thanks for your patience! Chuck