--- Begin Message ---
Subject: |
Abort in replace-regexp with an after-change-functions hook |
Date: |
Sat, 28 Jul 2012 12:53:33 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux) |
(If possible, please preserve the 682995-forwarded address in any replies.)
The following bug report was recently filed, and I've tried the example,
and saw the same abort.
You can find additional information here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682995
Christopher Wellons <address@hidden> writes:
> Package: emacs24
> Version: 24.1+1-4
> Severity: normal
>
> When this expression is evaluated, Emacs will abort.
>
> (with-temp-buffer
> (insert "#\n*\n")
> (goto-char (point-min))
> (add-hook 'after-change-functions
> (lambda (a b c) (re-search-forward "\n" nil t)))
> (replace-regexp "^\\*" " *"))
>
> It is also provided in an attached file, example.el, in order to make
> this easier to demonstrate.
>
> emacs -q -l example.el
>
> The abort() occurs in the check at the beginning of
> buf_charpos_to_bytepos() in marker.c, because the point has left the
> buffer bounds. I ran into this bug while trying to perform this
> replace-regexp while in a third-party markdown-mode, and narrowed it
> down to this combination of events.
>
> This bug also appears in emacs23 in both squeeze and sid as well as
> upstream and non-Debian builds of Emacs.
Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
--- End Message ---
--- Begin Message ---
Subject: |
Re: bug#12077: Abort in replace-regexp with an after-change-functions hook |
Date: |
Tue, 19 Feb 2013 12:08:34 -0500 |
User-agent: |
Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) |
Version: 24.4
Rob Browning wrote:
>> When this expression is evaluated, Emacs will abort.
>>
>> (with-temp-buffer
>> (insert "#\n*\n")
>> (goto-char (point-min))
>> (add-hook 'after-change-functions
>> (lambda (a b c) (re-search-forward "\n" nil t)))
>> (replace-regexp "^\\*" " *"))
By experiment, this issue is present in at least 22.3 through 24.2.93,
but is fixed in the current trunk.
--- End Message ---