From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Barry OReilly Newsgroups: gmane.emacs.bugs Subject: bug#14281: 24.3; replace-match leaves point at wrong place Date: Thu, 9 May 2013 15:07:51 -0400 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e0115efa654bd9204dc4dc440 X-Trace: ger.gmane.org 1368126544 4827 80.91.229.3 (9 May 2013 19:09:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 9 May 2013 19:09:04 +0000 (UTC) To: 14281@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu May 09 21:09: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 1UaWD9-0001W2-71 for geb-bug-gnu-emacs@m.gmane.org; Thu, 09 May 2013 21:09:03 +0200 Original-Received: from localhost ([::1]:38622 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UaWD8-0000Kq-II for geb-bug-gnu-emacs@m.gmane.org; Thu, 09 May 2013 15:09:02 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:52889) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UaWD4-0000KX-A2 for bug-gnu-emacs@gnu.org; Thu, 09 May 2013 15:09:00 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UaWD3-0006MY-2x for bug-gnu-emacs@gnu.org; Thu, 09 May 2013 15:08:58 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:59052) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UaWD2-0006MU-Vr for bug-gnu-emacs@gnu.org; Thu, 09 May 2013 15:08:57 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1UaWD8-0005cn-Ig for bug-gnu-emacs@gnu.org; Thu, 09 May 2013 15:09:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Barry OReilly Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 09 May 2013 19:09: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: X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.136812648621516 (code B ref -1); Thu, 09 May 2013 19:09:02 +0000 Original-Received: (at submit) by debbugs.gnu.org; 9 May 2013 19:08:06 +0000 Original-Received: from localhost ([127.0.0.1]:34928 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UaWCE-0005ay-10 for submit@debbugs.gnu.org; Thu, 09 May 2013 15:08:06 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:41364) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UaWCB-0005ap-VA for submit@debbugs.gnu.org; Thu, 09 May 2013 15:08:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UaWC4-0005mC-AF for submit@debbugs.gnu.org; Thu, 09 May 2013 15:07:57 -0400 Original-Received: from lists.gnu.org ([208.118.235.17]:48198) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UaWC4-0005m8-6h for submit@debbugs.gnu.org; Thu, 09 May 2013 15:07:56 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:52720) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UaWC1-0000IA-M3 for bug-gnu-emacs@gnu.org; Thu, 09 May 2013 15:07:56 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UaWC0-0005lk-EF for bug-gnu-emacs@gnu.org; Thu, 09 May 2013 15:07:53 -0400 Original-Received: from mail-ob0-x22a.google.com ([2607:f8b0:4003:c01::22a]:64599) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UaWC0-0005lZ-8O for bug-gnu-emacs@gnu.org; Thu, 09 May 2013 15:07:52 -0400 Original-Received: by mail-ob0-f170.google.com with SMTP id er7so1967301obc.29 for ; Thu, 09 May 2013 12:07:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=9i9fkzgJQFzX2GF4bTzfv18Lf3qAr2Acc1baaErbho0=; b=ZjMEaJ9YZp5Rsoy7E4tlU75lWMDjgTvviV1kuDMsECi1PWO7Bq0EHvnOiEV8AF2I8R 7WxqLE+crNtl3bmQZe0Kj/ZyhhxnKasgmZdfDpp+B52oyOrv0Lk9Lf17/6GPqxYkadSe Wd+saxUfcpMio2XrmLkygiwCttDxvu099Q6VMfEHkALAOMUpXYrBDP+xmxqyiCV2Hg+N CEnibbpZwQVxFaY33nnGCAmUpch38RGX5FjHzVX35AbhtkSek5yVX3eKuC6BqlJDHsKi siFKPeEQkjbZdBgvdNnngH1In98K9VJPlD7zL7EJvH7NT4kUEhP1nXUraG9E2QNNo7nE JllQ== X-Received: by 10.182.107.138 with SMTP id hc10mr5115435obb.22.1368126471320; Thu, 09 May 2013 12:07:51 -0700 (PDT) Original-Received: by 10.76.93.68 with HTTP; Thu, 9 May 2013 12:07:51 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x 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:74104 Archived-At: --089e0115efa654bd9204dc4dc440 Content-Type: text/plain; charset=ISO-8859-1 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. >> 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? --089e0115efa654bd9204dc4dc440 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I reproduced the issue again and investigated. Since I'm unsure how to = determine information about the Lisp system within GDB, I used debug statem= ents 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:
=A0=A0 semantic-change-fun= ction
=A0=A0 c-after-change
=A0=A0 jit-lock-after-change

searc= h_regs.start[0] first takes on the incorrect value inside c-after-change= 9;s call to save-match-data. Since c-after-change code seems correct, I det= ermined that the match-data function begins returning the incorrect value d= uring semantic-change-function. I am using CEDET r8557.

>> I suppose that caveat would pin the bug on one of the third pa= rty
>> packages I use. However, why couldn't Emacs save off th= e match-data
>> itself and restore it after the after-change-funct= ions? Is there any
>> legit situation where a change hook would want to change the
&g= t;> 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 th= e question, so I'll rephrase: Why does Emacs allow after-change-functio= ns to change the match-data beyond its scope? Or: why doesn't the signa= l_after_change C function do like set-match-data instead of leaving it to c= lient change hooks to do so?

--089e0115efa654bd9204dc4dc440--