* Args out of range: #<buffer test.org>, 0, 1
@ 2015-01-13 15:05 Sebastien Vauban
2015-01-13 15:52 ` Nicolas Richard
2015-01-13 16:21 ` Nicolas Goaziou
0 siblings, 2 replies; 6+ messages in thread
From: Sebastien Vauban @ 2015-01-13 15:05 UTC (permalink / raw)
To: emacs-orgmode-mXXj517/zsQ
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Args out of range: #<buffer test.org>, 0, 1
2015-01-13 15:05 Args out of range: #<buffer test.org>, 0, 1 Sebastien Vauban
@ 2015-01-13 15:52 ` Nicolas Richard
2015-01-13 20:40 ` Sebastien Vauban
2015-01-13 16:21 ` Nicolas Goaziou
1 sibling, 1 reply; 6+ messages in thread
From: Nicolas Richard @ 2015-01-13 15:52 UTC (permalink / raw)
To: Sebastien Vauban; +Cc: public-emacs-orgmode-mXXj517/zsQ
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
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Args out of range: #<buffer test.org>, 0, 1
2015-01-13 15:52 ` Nicolas Richard
@ 2015-01-13 20:40 ` Sebastien Vauban
2015-01-13 21:58 ` Nicolas Richard
0 siblings, 1 reply; 6+ messages in thread
From: Sebastien Vauban @ 2015-01-13 20:40 UTC (permalink / raw)
To: emacs-orgmode-mXXj517/zsQ
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Args out of range: #<buffer test.org>, 0, 1
2015-01-13 20:40 ` Sebastien Vauban
@ 2015-01-13 21:58 ` Nicolas Richard
2015-01-14 8:27 ` Sebastien Vauban
0 siblings, 1 reply; 6+ messages in thread
From: Nicolas Richard @ 2015-01-13 21:58 UTC (permalink / raw)
To: Sebastien Vauban; +Cc: public-emacs-orgmode-mXXj517/zsQ, Nicolas Goaziou
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Args out of range: #<buffer test.org>, 0, 1
2015-01-13 21:58 ` Nicolas Richard
@ 2015-01-14 8:27 ` Sebastien Vauban
0 siblings, 0 replies; 6+ messages in thread
From: Sebastien Vauban @ 2015-01-14 8:27 UTC (permalink / raw)
To: emacs-orgmode-mXXj517/zsQ
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Args out of range: #<buffer test.org>, 0, 1
2015-01-13 15:05 Args out of range: #<buffer test.org>, 0, 1 Sebastien Vauban
2015-01-13 15:52 ` Nicolas Richard
@ 2015-01-13 16:21 ` Nicolas Goaziou
1 sibling, 0 replies; 6+ messages in thread
From: Nicolas Goaziou @ 2015-01-13 16:21 UTC (permalink / raw)
To: Sebastien Vauban; +Cc: public-emacs-orgmode-mXXj517/zsQ
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2015-01-14 8:27 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-01-13 15:05 Args out of range: #<buffer test.org>, 0, 1 Sebastien Vauban
2015-01-13 15:52 ` Nicolas Richard
2015-01-13 20:40 ` Sebastien Vauban
2015-01-13 21:58 ` Nicolas Richard
2015-01-14 8:27 ` Sebastien Vauban
2015-01-13 16:21 ` Nicolas Goaziou
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).