emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed

* [BABEL][BUG] lists and inline src
@ 2012-09-18 21:48 cberry
  2012-09-19  7:31 ` Bastien
  0 siblings, 1 reply; 9+ messages in thread
From: cberry @ 2012-09-18 21:48 UTC (permalink / raw)
  To: emacs-orgmode


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

^ permalink raw reply	[flat|nested] 9+ messages in thread

• * Re: [BABEL][BUG] lists and inline src
    2012-09-18 21:48 [BABEL][BUG] lists and inline src cberry
  @ 2012-09-19  7:31 ` Bastien
    2012-09-19 15:45   ` cberry
    0 siblings, 1 reply; 9+ messages in thread
  From: Bastien @ 2012-09-19  7:31 UTC (permalink / raw)
    To: cberry; +Cc: emacs-orgmode
  
  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
  
  ^ permalink raw reply	[flat|nested] 9+ messages in thread

• • * Re: [BABEL][BUG] lists and inline src
      2012-09-19  7:31 ` Bastien
    @ 2012-09-19 15:45   ` cberry
      2012-09-19 23:50     ` [New Latex Exporter][BABEL][BUG] " Eric Schulte
      0 siblings, 1 reply; 9+ messages in thread
    From: cberry @ 2012-09-19 15:45 UTC (permalink / raw)
      To: emacs-orgmode
    
    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
    
    ^ permalink raw reply	[flat|nested] 9+ messages in thread

  • • * Re: [New Latex Exporter][BABEL][BUG] lists and inline src
        2012-09-19 15:45   ` cberry
      @ 2012-09-19 23:50     ` Eric Schulte
        2012-09-20 12:13       ` Nicolas Goaziou
        0 siblings, 1 reply; 9+ messages in thread
      From: Eric Schulte @ 2012-09-19 23:50 UTC (permalink / raw)
        To: cberry; +Cc: Nicolas Goaziou, emacs-orgmode
      
      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
      
      ^ permalink raw reply	[flat|nested] 9+ messages in thread

    • • * Re: [New Latex Exporter][BABEL][BUG] lists and inline src
          2012-09-19 23:50     ` [New Latex Exporter][BABEL][BUG] " Eric Schulte
        @ 2012-09-20 12:13       ` Nicolas Goaziou
          2012-09-20 14:28         ` Eric Schulte
          0 siblings, 1 reply; 9+ messages in thread
        From: Nicolas Goaziou @ 2012-09-20 12:13 UTC (permalink / raw)
          To: Eric Schulte; +Cc: emacs-orgmode, cberry
        
        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
        
        ^ permalink raw reply	[flat|nested] 9+ messages in thread

      • • * Re: [New Latex Exporter][BABEL][BUG] lists and inline src
            2012-09-20 12:13       ` Nicolas Goaziou
          @ 2012-09-20 14:28         ` Eric Schulte
            2012-09-20 17:07           ` Nicolas Goaziou
            0 siblings, 1 reply; 9+ messages in thread
          From: Eric Schulte @ 2012-09-20 14:28 UTC (permalink / raw)
            To: Nicolas Goaziou; +Cc: cberry, emacs-orgmode
          
          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
          
          ^ permalink raw reply	[flat|nested] 9+ messages in thread

        • • * Re: [New Latex Exporter][BABEL][BUG] lists and inline src
              2012-09-20 14:28         ` Eric Schulte
            @ 2012-09-20 17:07           ` Nicolas Goaziou
              2012-09-20 17:26             ` Eric Schulte
              0 siblings, 1 reply; 9+ messages in thread
            From: Nicolas Goaziou @ 2012-09-20 17:07 UTC (permalink / raw)
              To: Eric Schulte; +Cc: cberry, emacs-orgmode
            
            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
            
            ^ permalink raw reply	[flat|nested] 9+ messages in thread

          • • * Re: [New Latex Exporter][BABEL][BUG] lists and inline src
                2012-09-20 17:07           ` Nicolas Goaziou
              @ 2012-09-20 17:26             ` Eric Schulte
                2012-09-20 19:27               ` Nicolas Goaziou
                0 siblings, 1 reply; 9+ messages in thread
              From: Eric Schulte @ 2012-09-20 17:26 UTC (permalink / raw)
                To: Nicolas Goaziou; +Cc: emacs-orgmode, cberry, 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
              
              ^ permalink raw reply	[flat|nested] 9+ messages in thread

            • • * Re: [New Latex Exporter][BABEL][BUG] lists and inline src
                  2012-09-20 17:26             ` Eric Schulte
                @ 2012-09-20 19:27               ` Nicolas Goaziou
                  0 siblings, 0 replies; 9+ messages in thread
                From: Nicolas Goaziou @ 2012-09-20 19:27 UTC (permalink / raw)
                  To: Eric Schulte; +Cc: emacs-orgmode, cberry
                
                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,
                
                ^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2012-09-20 19:31 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-09-18 21:48 [BABEL][BUG] lists and inline src cberry
2012-09-19  7:31 ` Bastien
2012-09-19 15:45   ` cberry
2012-09-19 23:50     ` [New Latex Exporter][BABEL][BUG] " Eric Schulte
2012-09-20 12:13       ` Nicolas Goaziou
2012-09-20 14:28         ` Eric Schulte
2012-09-20 17:07           ` Nicolas Goaziou
2012-09-20 17:26             ` Eric Schulte
2012-09-20 19:27               ` Nicolas Goaziou

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).