Hello,
Sebastien Vauban <sva-news-D0wtAvR13HarG/idocf...@public.gmane.org>
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
