[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [O] Args out of range: #<buffer test.org>, 0, 1
From: |
Sebastien Vauban |
Subject: |
Re: [O] Args out of range: #<buffer test.org>, 0, 1 |
Date: |
Tue, 13 Jan 2015 21:40:01 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.4 (windows-nt) |
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