Re: [O] Args out of range: #buffer test.org, 0, 1
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
[O] Args out of range: #buffer test.org, 0, 1
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: [O] Args out of range: #buffer test.org, 0, 1
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
Re: [O] Args out of range: #buffer test.org, 0, 1
Hello, Sebastien Vauban sva-news-D0wtAvR13HarG/idocf...@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: [O] Args out of range: #buffer test.org, 0, 1
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: [O] Args out of range: #buffer test.org, 0, 1
Sebastien Vauban sva-news-D0wtAvR13HarG/idocf...@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.
