Args out of range: #<buffer test.org>, 0, 1

Args out of range: #<buffer test.org>, 0, 1

[Sebastien Vauban]

Hello,

I sometimes (or often?) have the above error when pressing `C-c C-v C-d'
onto some region (to put it in a code block).

Org is supposed to ask me which language it is for, and then wrap my
selection with the right #+begin/end_src markers. Instead, I get the
"args out of range" error.

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 is generated because `org-babel-where-is-src-block-head'
returned nil...

I now have two problems at least:

- 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?

- 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?

Clearly, there is some extra cause I did not identify yet. Can you help?

Best regards,
  Seb

-- 
Sebastien Vauban

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

[Nicolas Richard]

Hello,

Sebastien Vauban <sva-news-D0wtAvR13HarG/iDocfnWg@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

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

[Nicolas Goaziou]

Hello,

Sebastien Vauban <sva-news-D0wtAvR13HarG/iDocfnWg@public.gmane.org>
writes:

> I sometimes (or often?) have the above error when pressing `C-c C-v C-d'
> onto some region (to put it in a code block).
>
> Org is supposed to ask me which language it is for, and then wrap my
> selection with the right #+begin/end_src markers. Instead, I get the
> "args out of range" error.

This should be fixed. Thank you for reporting it.


Regards,

-- 
Nicolas Goaziou

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

[Sebastien Vauban]

Hello both Nicolas,

Nicolas Richard wrote:
> Sebastien Vauban 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 ?

I cannot exclude that.  In the minimal Emacs, I loose so many effective
key bindings that it takes me a while to do what I want to do ;-)

>> - 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.)

Thanks for the explanation.

This still leaves me with one question: how do we reproduce the problem?
What's the trigger for it?

PS- @NicolasG, thanks for fixing it...

Best regards,
  Seb

-- 
Sebastien Vauban

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

[Nicolas Richard]

Sebastien Vauban <sva-news-D0wtAvR13HarG/iDocfnWg@public.gmane.org>
writes:
> This still leaves me with one question: how do we reproduce the problem?
> What's the trigger for it?

Mostly luck. i.e. you need to have called a function that callled
string-match on a string, with a regexp containing (at least) 4 grouping
constructs, and the 4th matched at the beginning of that string
(beginning position 0) but only one character (end position 1) [1]. And
then later call org-babel-demarcate-block. Between the two, many things
may have happened as long as the match data was preserved.

[1] I gave an example of such a call to string-match -- my example
wasn't super useful I admit. In your case, it could be anything : not
necessarily an org function. Many functions use string-match internally.

> PS- @NicolasG, thanks for fixing it...

And also thanks for mentionning org-babel-src-block-regexp... and
completely rewriting org-babel-where-is-src-block-head. Very impressive!

-- 
Nicolas.

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

[Sebastien Vauban]

Nicolas Richard wrote:
> Sebastien Vauban writes:
>> This still leaves me with one question: how do we reproduce the
>> problem?  What's the trigger for it?
>
> Mostly luck. i.e. you need to have called a function that callled
> string-match on a string, with a regexp containing (at least)
> 4 grouping constructs, and the 4th matched at the beginning of that
> string (beginning position 0) but only one character (end position
> 1). And then later call org-babel-demarcate-block. Between the two,
> many things may have happened as long as the match data was preserved.

OK. I understand now I had problems figuring out what the trigger was
for the problem...

>> PS- @NicolasG, thanks for fixing it...
>
> And also thanks for mentionning org-babel-src-block-regexp... and
> completely rewriting org-babel-where-is-src-block-head. Very
> impressive!

Yep, that was quick (as very often).

Best regards,
  Seb

-- 
Sebastien Vauban