[BABEL][BUG] lists and inline src

[BABEL][BUG] lists and inline src

[cberry]

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

Re: [BABEL][BUG] lists and inline src

[Bastien]

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

Re: [BABEL][BUG] lists and inline src

[cberry]

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

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

[Eric Schulte]

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

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

[Nicolas Goaziou]

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

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

[Eric Schulte]

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

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

[Nicolas Goaziou]

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

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

[Eric Schulte]

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

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

[Nicolas Goaziou]

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,