[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#14281: 24.3; replace-match leaves point at wrong place
From: |
Stefan Monnier |
Subject: |
bug#14281: 24.3; replace-match leaves point at wrong place |
Date: |
Thu, 09 May 2013 17:27:10 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) |
> I reproduced the issue again and investigated. Since I'm unsure how to
> determine information about the Lisp system within GDB, I used debug
> statements in C and Lisp to arrive at the following description of what
> happens, additive to my previous description:
> My after-change-functions, in order, are:
> semantic-change-function
> c-after-change
> jit-lock-after-change
> search_regs.start[0] first takes on the incorrect value inside
> c-after-change's call to save-match-data. Since c-after-change code seems
> correct, I determined that the match-data function begins returning the
> incorrect value during semantic-change-function. I am using CEDET r8557.
Not sure what CEDET r8557 does, but at least the CEDET code in Emacs's
trunk is pretty simple in this respect: semantic-change-function only
runs the semantic-change-functions hook, and grep seems to indicate that
this hook is never modified, so the whole thing should never get
anywhere near the match-data.
Note that there are other change functions than after-change-functions.
There's also before-change-functions and there are overlays's
modification-hooks. You might like to check those as well.
>>> I suppose that caveat would pin the bug on one of the third party
>>> packages I use. However, why couldn't Emacs save off the match-data
>>> itself and restore it after the after-change-functions? Is there any
>>> legit situation where a change hook would want to change the
>>> match-data in effect after the change hook returns?
Stefan> There are many cases where an after-change-function won't use regular
Stefan> expressions at all.
> The answer doesn't seem to fit the question, so I'll rephrase: Why does
> Emacs allow after-change-functions to change the match-data beyond its
> scope? Or: why doesn't the signal_after_change C function do like
> set-match-data instead of leaving it to client change hooks to do so?
Because it wastes time in most cases (when after-change-functions
won't use regular expressions at all).
Maybe we could add code that saves just the (match-beginning 0) and
signals an error if it was not properly preserved. This would still
require change-functions to save the match-data if they use it, but it
might catch the offenders earlier.
Stefan
- bug#14281: 24.3; replace-match leaves point at wrong place, Barry OReilly, 2013/05/09
- bug#14281: 24.3; replace-match leaves point at wrong place,
Stefan Monnier <=
- bug#14281: 24.3; replace-match leaves point at wrong place, Barry OReilly, 2013/05/10
- bug#14281: 24.3; replace-match leaves point at wrong place, Barry OReilly, 2013/05/10
- bug#14281: 24.3; replace-match leaves point at wrong place, Stefan Monnier, 2013/05/10
- bug#14281: 24.3; replace-match leaves point at wrong place, Barry OReilly, 2013/05/14
- bug#14281: 24.3; replace-match leaves point at wrong place, Barry OReilly, 2013/05/15
- bug#14281: 24.3; replace-match leaves point at wrong place, Stefan Monnier, 2013/05/15
- bug#14281: 24.3; replace-match leaves point at wrong place, Barry OReilly, 2013/05/15
- bug#14281: 24.3; replace-match leaves point at wrong place, Barry OReilly, 2013/05/15
- bug#14281: 24.3; replace-match leaves point at wrong place, Stefan Monnier, 2013/05/21