From: Sebastien Vauban <sva-news-D0wtAvR13HarG/iDocfnWg@public.gmane.org>
To: emacs-orgmode-mXXj517/zsQ@public.gmane.org
Subject: Re: Args out of range: #<buffer test.org>, 0, 1
Date: Tue, 13 Jan 2015 21:40:01 +0100 [thread overview]
Message-ID: <86r3uyo1ni.fsf@example.com> (raw)
In-Reply-To: 874mrulluj.fsf@yahoo.fr
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
next prev parent reply other threads:[~2015-01-13 20:40 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2015-01-13 21:58 ` Nicolas Richard
2015-01-14 8:27 ` Sebastien Vauban
2015-01-13 16:21 ` Nicolas Goaziou
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86r3uyo1ni.fsf@example.com \
--to=sva-news-d0wtavr13harg/idocfnwg@public.gmane.org \
--cc=emacs-orgmode-mXXj517/zsQ@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).