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: Wed, 15 May 2013 11:03:58 -0400 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b47249e3028ef04dcc30ffd X-Trace: ger.gmane.org 1368630312 14967 80.91.229.3 (15 May 2013 15:05:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 15 May 2013 15:05:12 +0000 (UTC) Cc: 14281@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed May 15 17:05:11 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 1UcdGR-00040E-5r for geb-bug-gnu-emacs@m.gmane.org; Wed, 15 May 2013 17:05:11 +0200 Original-Received: from localhost ([::1]:36240 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UcdGQ-0004AM-9B for geb-bug-gnu-emacs@m.gmane.org; Wed, 15 May 2013 11:05:10 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:58271) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UcdGI-00047j-Rx for bug-gnu-emacs@gnu.org; Wed, 15 May 2013 11:05:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UcdGD-0001BK-Iw for bug-gnu-emacs@gnu.org; Wed, 15 May 2013 11:05:02 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:57776) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UcdGD-0001BD-BN for bug-gnu-emacs@gnu.org; Wed, 15 May 2013 11:04:57 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1UcdGH-00071t-W6 for bug-gnu-emacs@gnu.org; Wed, 15 May 2013 11:05: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: Wed, 15 May 2013 15:05:01 +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.136863025226932 (code B ref 14281); Wed, 15 May 2013 15:05:01 +0000 Original-Received: (at 14281) by debbugs.gnu.org; 15 May 2013 15:04:12 +0000 Original-Received: from localhost ([127.0.0.1]:46133 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UcdFU-00070L-0g for submit@debbugs.gnu.org; Wed, 15 May 2013 11:04:12 -0400 Original-Received: from mail-ob0-f180.google.com ([209.85.214.180]:43669) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UcdFR-000701-Gy for 14281@debbugs.gnu.org; Wed, 15 May 2013 11:04:10 -0400 Original-Received: by mail-ob0-f180.google.com with SMTP id xk17so2058502obc.39 for <14281@debbugs.gnu.org>; Wed, 15 May 2013 08:03:58 -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:cc:content-type; bh=yfJizdyKEekIYS5MNHc3rZ8O+CCiX8OSnhMXAamxa9Q=; b=Aat/BBu2Cb+9JdhpLadB9KyYNQYvTkxEKNEKxsROXiCGgOpmgl//hIJfIi8VCSBJwT 91quuMXQBXBXwgvghmZWasr+q48TuXcxA+1lvY6xVzLIqQgdsnn9zzgsam6K78yIs2dx qiFTy7o+s++V09522PtAyZG2Lbu7nDw2feA1A65nBPDsu16r2ZIT/e37iT3zDpTyTEB2 smfWp7V5jO9kNoQOOeu5kdMZjQtsRTI+B6Olfp4TDWSjnDv7tODQnjwj1KlkeAhE6xG6 9/7YRKyKCY2okykkwgBivvu5Uaffj9Nd8elVEKwJ9wU9wijR1QQ8Qoz36yfuZbfFHE+r QZvA== X-Received: by 10.60.133.134 with SMTP id pc6mr19436534oeb.87.1368630238388; Wed, 15 May 2013 08:03:58 -0700 (PDT) Original-Received: by 10.76.93.68 with HTTP; Wed, 15 May 2013 08:03:58 -0700 (PDT) In-Reply-To: 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:74297 Archived-At: --047d7b47249e3028ef04dcc30ffd Content-Type: text/plain; charset=ISO-8859-1 To clarify and expand on the previous: (defadvice evil-track-last-insertion (around my-advice-evil-track-last-insertion activate) (my-msg "DEBUG: 01a evil-track-last-insertion match-beginning=%s match-end=%s match-data=%s" (match-beginning 0) (match-end 0) (match-data)) (save-match-data ad-do-it) (my-msg "DEBUG: 01b evil-track-last-insertion match-beginning=%s match-end=%s match-data=%s" (match-beginning 0) (match-end 0) (match-data)) ) Causes output: 2013-05-15T09:15:21.604604 DEBUG: 01a evil-track-last-insertion match-beginning=0 match-end=5 match-data=(# # # #) 2013-05-15T09:15:21.613707 DEBUG: 01b evil-track-last-insertion match-beginning=1 match-end=5 match-data=(# # # #) (match-beginning 0) evaluates to 0 while the first element of (match-data) is a marker at 1. Is this discrepancy expected? I determined the reason for the discrepancy is that when match-data creates the markers, set-marker can adjust the position. This puts the markers saved and restored through save-match-data out of sync with the search_regs. I suspect this is a problem since replace-match assumes search_regs don't change during change hooks. It certainly creates a problem for the error checking approach. --047d7b47249e3028ef04dcc30ffd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable To clarify and expand on the previous:

(defadvice evil-track-last-in= sertion (around my-advice-evil-track-last-insertion activate)
=A0 (my-ms= g "DEBUG: 01a evil-track-last-insertion match-beginning=3D%s match-end= =3D%s match-data=3D%s" (match-beginning 0) (match-end 0) (match-data))=
=A0 (save-match-data ad-do-it)
=A0 (my-msg "DEBUG: 01b evil-track-l= ast-insertion match-beginning=3D%s match-end=3D%s match-data=3D%s" (ma= tch-beginning 0) (match-end 0) (match-data))
=A0 )

Causes output= :

2013-05-15T09:15:21.604604 DEBUG: 01a evil-track-last-insertion match-begin= ning=3D0 match-end=3D5 match-data=3D(#<marker at 1 in Redacted.cc> #&= lt;marker at 5 in Redacted.cc> #<marker at 4 in Redacted.cc> #<= marker at 5 in Redacted.cc>)
2013-05-15T09:15:21.613707 DEBUG: 01b evil-track-last-insertion match-begin= ning=3D1 match-end=3D5 match-data=3D(#<marker at 1 in Redacted.cc> #&= lt;marker at 5 in Redacted.cc> #<marker at 4 in Redacted.cc> #<= marker at 5 in Redacted.cc>)

(match-beginning 0) evaluates to 0 while the first element of (match-da= ta) is a marker at 1. Is this discrepancy expected?

I determined the= reason for the discrepancy is that when match-data creates the markers, se= t-marker can adjust the position. This puts the markers saved and restored = through save-match-data out of sync with the search_regs. I suspect this is= a problem since replace-match assumes search_regs don't change during = change hooks. It certainly creates a problem for the error checking approac= h.

--047d7b47249e3028ef04dcc30ffd--