emacs-orgmode
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]