From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#31492: 26.1; query-replace-regexp undo fails in regexps w/o printable chars Date: Sun, 20 May 2018 12:29:07 +0300 Message-ID: <83vabifzfg.fsf@gnu.org> References: <8736yp14c7.fsf@gmail.com> <838t8hhwwu.fsf@gnu.org> <837eo1huji.fsf@gnu.org> <83zi0wgk3d.fsf@gnu.org> <87tvr3zpm4.fsf@gmail.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1526808488 29979 195.159.176.226 (20 May 2018 09:28:08 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 20 May 2018 09:28:08 +0000 (UTC) Cc: 31492@debbugs.gnu.org To: Tino Calancha Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun May 20 11:28:04 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fKKdH-0007hD-N1 for geb-bug-gnu-emacs@m.gmane.org; Sun, 20 May 2018 11:28:03 +0200 Original-Received: from localhost ([::1]:45852 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fKKfO-00058I-R0 for geb-bug-gnu-emacs@m.gmane.org; Sun, 20 May 2018 05:30:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36307) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fKKfG-00057s-E5 for bug-gnu-emacs@gnu.org; Sun, 20 May 2018 05:30:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fKKfD-0005O2-9Z for bug-gnu-emacs@gnu.org; Sun, 20 May 2018 05:30:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:33732) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fKKfD-0005Ny-6i for bug-gnu-emacs@gnu.org; Sun, 20 May 2018 05:30:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1fKKfC-0003lM-SA for bug-gnu-emacs@gnu.org; Sun, 20 May 2018 05:30:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 20 May 2018 09:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 31492 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 31492-submit@debbugs.gnu.org id=B31492.152680855814383 (code B ref 31492); Sun, 20 May 2018 09:30:02 +0000 Original-Received: (at 31492) by debbugs.gnu.org; 20 May 2018 09:29:18 +0000 Original-Received: from localhost ([127.0.0.1]:41628 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fKKeT-0003jv-VC for submit@debbugs.gnu.org; Sun, 20 May 2018 05:29:18 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:45236) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fKKeS-0003jh-9N for 31492@debbugs.gnu.org; Sun, 20 May 2018 05:29:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fKKeJ-00056C-Uj for 31492@debbugs.gnu.org; Sun, 20 May 2018 05:29:11 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:57314) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fKKeJ-000564-Qq; Sun, 20 May 2018 05:29:07 -0400 Original-Received: from [176.228.60.248] (port=4218 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1fKKeI-0006GH-85; Sun, 20 May 2018 05:29:06 -0400 In-reply-to: <87tvr3zpm4.fsf@gmail.com> (message from Tino Calancha on Sat, 19 May 2018 23:28:35 +0900) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.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" Xref: news.gmane.org gmane.emacs.bugs:146315 Archived-At: > From: Tino Calancha > Cc: 31492@debbugs.gnu.org > Date: Sat, 19 May 2018 23:28:35 +0900 > > > The relevant > > element of the replacement stack (whose structure, btw, seems not to > > be documented anywhere), is (4 4 *scratch*), whereas I'd expect to see > > (1 4 *scratch) instead, because the replacement was at position 1; > > then setting match-data from this would DTRT. > Yes, that is the logic. The thing is, for some unknown reason to me, > the reported match-data is inexact when there are no printable chars > in the regexp (maybe it's expected and I am wrong on my assumptions). The reason for that is that match-data is recorded as markers, and so the positions move if text is inserted. In your example, the position of $ moved due to insertion, so the marker's position was updated as part of the replacement. > (with-temp-buffer > (insert "foo") > (goto-char 1) > (progn (re-search-forward "$" nil t) > (save-match-data (replace-match "ZZZ")) > (list (point) (match-beginning 0) (match-end 0)))) > => (7 7 7) > ;; If this would be (7 4 7), then we could use `looking-at'; we are to > ;; the right of the replacement, then we use `looking-back'. > > > ;; But the match was at 4 not at 7 > (with-temp-buffer > (insert "foo") > (goto-char 1) > (progn (re-search-forward "$" nil t) > (list (point) (match-beginning 0) (match-end 0)))) > => (4 4 4) Right, and so I submit that the problem is where the replacement stack is updated: it should account for these subtleties and adjust the stack positions accordingly, since it has the opportunity to look at the match position before the matched text is replaced. It is IMO suboptimal to make these adjustments where the stack is used, because you've lost the information about the actual match point, and you are deducing it using heuristics, which I'm not sure is 100% reliable. Thanks.