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

["Charles C. Berry" <ccberry@ucsd.edu>]

On Mon, 19 Jan 2015, Nicolas Goaziou wrote:

> "Charles C. Berry" <ccberry@ucsd.edu> 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