Re: [O] Args out of range: #<buffer test.org>, 0, 1

[Nicolas Richard]

Hello,

Sebastien Vauban <sva-news-D0wtAvR13HarG/address@hidden>
writes:
> I tried to edebug the function `org-babel-demarcate-block' and the error
> arises quite at the beginning: on the `match-string 0', on the second
> line of the `let*'.

The error means we tried to access portions from 0 to 1 in a buffer.
That doesn't exist. The reason is that the match data was built when
matching on a string (where 0 is a valid position), and we're trying to
use it on a buffer. It simply means that we're trying to access the
match data without actually checking that we matched something.

Reproduce with:
(progn (string-match "\\(\\(\\(\\(.\\)\\)\\)\\)" "foo") ; this sets the match 
data
       (with-temp-buffer
         (org-babel-demarcate-block))) ; tries to access the match data,
                                       ; but never matched anything successfully

> - I can't reproduce it in a minimal Emacs, and there... edebug ends in
>   an error (I wanted to compare the execution steps), as you can see on
>   the right screen of http://screencast.com/t/A5ldV2yHNna.
>   
>   Why is edebug crashing?

Did you perhaps kill the buffer where org-babel-demarcate-block
was instrumented for edebug ?

> - It seems normal that `org-babel-where-is-src-block-head' returns nil
>   when we use `C-c C-v C-d' to create the first code block in a buffer
>   which did not contain any... and it works in my minimal Emacs... (iff
>   edebug is turned off)
>
> Any idea of the problem, then?

I think the `progn' in org-babel-demarcate-block should be `and'.

(I also think that the fact that the match data is set according to
org-babel-src-block-regexp when calling
org-babel-where-is-src-block-head should be documented in that
function. Relying on undocumented side effects is nasty.)

HTH,

-- 
Nico