Nicolas Goaziou <n.goaz...@gmail.com> writes: > Hello, > > Eric Schulte <eric.schu...@gmx.com> 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