Re: [O] [New Latex Exporter][BABEL][BUG] lists and inline src

[Eric Schulte]

Nicolas Goaziou <address@hidden> writes:

> Hello,
>
> Eric Schulte <address@hidden> writes:
>
>> Does this problem present itself when you execute the inline code block
>> interactively, or only when using the new latex exporter?  If the later
>> then it is a latex exporter bug and not a Babel bug.  I've updated the
>> subject line so that hopefully the latex export experts will notice this
>> message.
>
> Indeed, the parser doesn't understand:
>
>   - src_emacs-lisp{(+ 1 2)}
>
> That's a bug. The problem is related to
> `org-babel-inline-src-block-regexp', which is used by the parser. More
> accurately, at the beginning of that regexp, there is:
>
>   "\\(?:^\\|[^-[:alnum:]]\\)\\(src_"
>
> Item contents start at the "s" from "src" but the regexp cannot match
> from there. So, is "[^-[:alnum:]]" (and, therefore,
> "\\(?:^\\|[^-[:alnum:]]\\)") really necessary? Why couldn't an user be
> able to write an inline-src-block in the middle of something (for
> example with raw results)?
>

Thanks for finding the source of this problem.  The preceding character
is checked so that inline source blocks can be commented.  E.g., a user
may want =src_sh{date}= to appear verbatim.  Similarly if the preceding
character is a letter e.g., notsrc_sh{date}, then the source block
should not be executed.

>
> If checking the character before the inline-src-block object is
> mandatory, I'll have to rely on an hack in org-element.el, along the
> lines of:
>
>   #+begin_src emacs-lisp
>   (save-excursion
>     (unless (bolp) (backward-char))
>     (re-search-forward org-babel-inline-src-block-regexp nil limit)
>     ...)  
>   #+end_src
>
> Obviously, I'd rather have the first part of the regexp removed.
>
> What do you think?
>

Ideally there would be a way to specify that *if* a character exists
before the code block it must have some property, or to match the
beginning of the element as another regexp option.  I would say we can
go ahead and remove the leading portion of the regexp, but as I recall I
wrote it in response to legitimate complaints on the mailing list about
the overly permissive behavior of inline source blocks, and I do not
want for those problems to re-emerge.

Best,

>
>
> Regards,

-- 
Eric Schulte
http://cs.unm.edu/~eschulte