From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#14281: 24.3; replace-match leaves point at wrong place Date: Thu, 09 May 2013 17:27:10 -0400 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1368134884 28325 80.91.229.3 (9 May 2013 21:28:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 9 May 2013 21:28:04 +0000 (UTC) Cc: 14281@debbugs.gnu.org To: Barry OReilly Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu May 09 23:28:03 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UaYNe-0002AH-4z for geb-bug-gnu-emacs@m.gmane.org; Thu, 09 May 2013 23:28:02 +0200 Original-Received: from localhost ([::1]:47150 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UaYNd-0005ee-CC for geb-bug-gnu-emacs@m.gmane.org; Thu, 09 May 2013 17:28:01 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:37760) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UaYNZ-0005eT-9y for bug-gnu-emacs@gnu.org; Thu, 09 May 2013 17:27:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UaYNY-0003GG-9I for bug-gnu-emacs@gnu.org; Thu, 09 May 2013 17:27:57 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:59202) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UaYNY-0003GC-5q for bug-gnu-emacs@gnu.org; Thu, 09 May 2013 17:27:56 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1UaYNe-0003ct-1a for bug-gnu-emacs@gnu.org; Thu, 09 May 2013 17:28:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 09 May 2013 21:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 14281 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 14281-submit@debbugs.gnu.org id=B14281.136813484213820 (code B ref 14281); Thu, 09 May 2013 21:28:02 +0000 Original-Received: (at 14281) by debbugs.gnu.org; 9 May 2013 21:27:22 +0000 Original-Received: from localhost ([127.0.0.1]:35078 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UaYN0-0003ar-1K for submit@debbugs.gnu.org; Thu, 09 May 2013 17:27:22 -0400 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:57695) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UaYMw-0003ac-Lx for 14281@debbugs.gnu.org; Thu, 09 May 2013 17:27:20 -0400 Original-Received: from faina.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id r49LRAoG005455; Thu, 9 May 2013 17:27:10 -0400 Original-Received: by faina.iro.umontreal.ca (Postfix, from userid 20848) id 65E94B40D8; Thu, 9 May 2013 17:27:10 -0400 (EDT) In-Reply-To: (Barry OReilly's message of "Thu, 9 May 2013 15:07:51 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV4574=0 X-NAI-Spam-Version: 2.3.0.9362 : core <4574> : streams <957511> : uri <1415945> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:74109 Archived-At: > 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