I reproduced the issue again and investigated. Since I&#39;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:<br>
<br>My after-change-functions, in order, are:<br>   semantic-change-function<br>   c-after-change<br>   jit-lock-after-change<br><br>search_regs.start[0] first takes on the incorrect value inside c-after-change&#39;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.<br>
<br>&gt;&gt; I suppose that caveat would pin the bug on one of the third party<br>&gt;&gt; packages I use. However, why couldn&#39;t Emacs save off the match-data<br>&gt;&gt; itself and restore it after the after-change-functions? Is there any<br>
&gt;&gt; legit situation where a change hook would want to change the<br>&gt;&gt; match-data in effect after the change hook returns?<br><br>Stefan&gt; There are many cases where an after-change-function won&#39;t use regular<br>
Stefan&gt; expressions at all.<br><br>The answer doesn&#39;t seem to fit the question, so I&#39;ll rephrase: Why does Emacs allow after-change-functions to change the match-data beyond its scope? Or: why doesn&#39;t the signal_after_change C function do like set-match-data instead of leaving it to client change hooks to do so?<br>
<br>