Re: [O] New patches WAS Re: [PATCH] inline src block results can be removed

[Charles C. Berry]

On Mon, 19 Jan 2015, Nicolas Goaziou wrote:

> "Charles C. Berry" <address@hidden> 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 "{{{<name>(" 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