My apologies if this is already reported (I recall seeing something like this, but cannot find it in the archives). A list element starting with an inline src block is improperly parsed. for example - src_emacs-lisp{(org-version)} is not executed by babel. An ECM: ,---- | * virgin version | | The version is src_emacs-lisp{(org-version)} | | * list versions | | - The version is | - src_emacs-lisp{(org-version)} | - The version is | - now src_emacs-lisp{(org-version)} `---- yields ,---- | ... | \section{virgin version} | \label{sec-1} | | | The version is \verb=7.9.1= | \section{list versions} | \label{sec-2} | | | \begin{itemize} | \item The version is | \item src$_{\mathrm{emacs}}$-lisp\{(org-version)\} | \item The version is | \item now \verb=7.9.1= | \end{itemize} | ... `---- Chuck
Hi Chuck,
cberry@tajo.ucsd.edu writes:
> My apologies if this is already reported (I recall seeing something like
> this, but cannot find it in the archives).
>
> A list element starting with an inline src block is improperly
> parsed.
I cannot reproduce this with Org 7.9.1.
--
Bastien
Bastien <bzg@altern.org> writes:
> Hi Chuck,
>
> cberry@tajo.ucsd.edu writes:
>
>> My apologies if this is already reported (I recall seeing something like
>> this, but cannot find it in the archives).
>>
>> A list element starting with an inline src block is improperly
>> parsed.
>
> I cannot reproduce this with Org 7.9.1.
I just did a git pull, trimmed my .emacs down to
(setq load-path (cons "~/elisp/org-mode/lisp" load-path))
(setq load-path (cons "~/elisp/org-mode/contrib/lisp" load-path))
renamed customizations.el, started Aquamacs, loaded org-e-latex.el and
reran
(org-export-to-buffer 'e-latex "*Test e-LaTeX*" nil nil t)
I am still getting the same result.
What else can I do to get to the bottom of this??
Chuck
cberry@tajo.ucsd.edu writes: > Bastien <bzg@altern.org> writes: > >> Hi Chuck, >> >> cberry@tajo.ucsd.edu writes: >> >>> My apologies if this is already reported (I recall seeing something like >>> this, but cannot find it in the archives). >>> >>> A list element starting with an inline src block is improperly >>> parsed. >> >> I cannot reproduce this with Org 7.9.1. > > I just did a git pull, trimmed my .emacs down to > > (setq load-path (cons "~/elisp/org-mode/lisp" load-path)) > (setq load-path (cons "~/elisp/org-mode/contrib/lisp" load-path)) > > renamed customizations.el, started Aquamacs, loaded org-e-latex.el and > reran > > (org-export-to-buffer 'e-latex "*Test e-LaTeX*" nil nil t) > > I am still getting the same result. > > What else can I do to get to the bottom of this?? > Hi Chuck, 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. Cheers, > > Chuck > > -- Eric Schulte http://cs.unm.edu/~eschulte
Hello,
Eric Schulte <eric.schulte@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)?
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?
Regards,
--
Nicolas Goaziou
Nicolas Goaziou <n.goaziou@gmail.com> writes: > Hello, > > Eric Schulte <eric.schulte@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
Hello, Eric Schulte <eric.schulte@gmx.com> writes: > 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. =src_sh{date}= won't be expanded by `org-babel-exp-non-block-elements' (is there another function executing them?) since the current version checks object at point (in this case, it is a verbatim object, not an inline-src-block). So, in this case, there's no need for the check. > Similarly if the preceding character is a letter e.g., > notsrc_sh{date}, then the source block should not be executed. I don't understand why it wouldn't be expanded in that situation. It can be useful if results are raw: it becomes a beefed-up macro. > 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. I understand, but it looks like a very drastic solution. It may be worth reconsidering it for 8.x branch. If problems re-emerge then, test cases will be provided. What do you think about it? For 7.9.x, I'll just commit the workaround. Regards, -- Nicolas Goaziou
Nicolas Goaziou <n.goaziou@gmail.com> writes: > Hello, > > Eric Schulte <eric.schulte@gmx.com> writes: > >> 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. > > =src_sh{date}= won't be expanded by `org-babel-exp-non-block-elements' > (is there another function executing them?) since the current version > checks object at point (in this case, it is a verbatim object, not an > inline-src-block). So, in this case, there's no need for the check. > >> Similarly if the preceding character is a letter e.g., >> notsrc_sh{date}, then the source block should not be executed. > > I don't understand why it wouldn't be expanded in that situation. It can > be useful if results are raw: it becomes a beefed-up macro. > >> 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. > > I understand, but it looks like a very drastic solution. It may be worth > reconsidering it for 8.x branch. If problems re-emerge then, test cases > will be provided. What do you think about it? > > For 7.9.x, I'll just commit the workaround. > Yea, that sounds reasonable, thanks for taking care of this. If I find time I'll dig through the mailing list and see if I can find the exact reason why that portion of the regexp was added. I've had the experience before of reverting a piece of code that seemed superfluous to then have old bugs re-emerge and finally revert my reversion. So I now try to err on the side of deference towards existing code. Cheers, > > > Regards, -- Eric Schulte http://cs.unm.edu/~eschulte
Eric Schulte <eric.schulte@gmx.com> writes: > Yea, that sounds reasonable, thanks for taking care of this. If I find > time I'll dig through the mailing list and see if I can find the exact > reason why that portion of the regexp was added. That would be a great starting point to avoid repeating past mistakes. > I've had the experience before of reverting a piece of code that seemed > superfluous to then have old bugs re-emerge and finally revert my > reversion. So I now try to err on the side of deference towards > existing code. I know the feeling. But I'm pretty confident on this one. BTW, the bug should be fixed in 7.9.x now. Regards,