From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#23484: 25.1.50; undo doesn't work properly in xref-query-replace-in-results Date: Fri, 13 May 2016 01:01:53 +0300 Message-ID: <783855a4-8ac2-f53c-7722-eacf530d732c@yandex.ru> References: <86d1owl682.fsf@yandex.ru> <87inyoxpz8.fsf@mail.linkov.net> <8760unxaoi.fsf@mail.linkov.net> <118c4316-9179-c9dd-e7d1-97b96921d922@yandex.ru> <8737pp1tt6.fsf@mail.linkov.net> <87k2j0b9sk.fsf@mail.linkov.net> <87eg97hu2s.fsf@mail.linkov.net> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1463090607 2523 80.91.229.3 (12 May 2016 22:03:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 12 May 2016 22:03:27 +0000 (UTC) Cc: 23484@debbugs.gnu.org To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri May 13 00:03:17 2016 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 1b0yhL-0002Rx-NY for geb-bug-gnu-emacs@m.gmane.org; Fri, 13 May 2016 00:03:11 +0200 Original-Received: from localhost ([::1]:59983 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b0yhL-000185-2y for geb-bug-gnu-emacs@m.gmane.org; Thu, 12 May 2016 18:03:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48214) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b0yhF-00016o-Qz for bug-gnu-emacs@gnu.org; Thu, 12 May 2016 18:03:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b0yhC-0008U2-It for bug-gnu-emacs@gnu.org; Thu, 12 May 2016 18:03:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:37068) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b0yhC-0008Tx-FQ for bug-gnu-emacs@gnu.org; Thu, 12 May 2016 18:03:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1b0yhC-0003nI-5j for bug-gnu-emacs@gnu.org; Thu, 12 May 2016 18:03:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 12 May 2016 22:03:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23484 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 23484-submit@debbugs.gnu.org id=B23484.146309052314519 (code B ref 23484); Thu, 12 May 2016 22:03:02 +0000 Original-Received: (at 23484) by debbugs.gnu.org; 12 May 2016 22:02:03 +0000 Original-Received: from localhost ([127.0.0.1]:49405 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1b0ygF-0003m6-79 for submit@debbugs.gnu.org; Thu, 12 May 2016 18:02:03 -0400 Original-Received: from mail-wm0-f52.google.com ([74.125.82.52]:37534) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1b0ygD-0003la-Ik for 23484@debbugs.gnu.org; Thu, 12 May 2016 18:02:01 -0400 Original-Received: by mail-wm0-f52.google.com with SMTP id a17so815952wme.0 for <23484@debbugs.gnu.org>; Thu, 12 May 2016 15:02:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=aMHe3Yga3WAOu0B3sxf4L09nFJURKHWMCjEyXSDjM18=; b=cPhdov92HCOG17+3ZPFLBuuMAS/ZqaDDs0dv/1BjtVLqe5aIbgb+mAN6m9fIfqUOva 9KLWIUrvwxpruzNX8SDfQX2X3BNbQh8+IYSJjZ84fEofgb+Xj/W+wNygd1XZsE5NxOnJ 65Dn5ARwuMrJyGNaRMbLJktqOCyVyTMgrtaq0Zy4NCqy8TLvYFdPm+azOTiZEnIIrm+L WUtbnu5zqJtde6xRuivuEmEEYhZEBHfF3RDXZ5fqWi0m4XGQLOE+vwfqZD55UUkCGwvF Zd/hl2zF0XzuliQYwOENYB4GWIm//VLt4BzQTMuS64S2u97DA+rFazXHrmDqiY2G7QDL 6/hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:to:references:cc:from:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=aMHe3Yga3WAOu0B3sxf4L09nFJURKHWMCjEyXSDjM18=; b=Cmr3/6ebSXgMYuBkGWZnCiFrD9lGekLL+YVrY86ZHpcKIQcgsF/qbu03IQ9LHhN37L iq+BCPXtVqQSeRfAu9NtbeULSjofwhjuOJ2hbFMJeEiIfXVVFXw5aVKQXBOrD4qzzdWT gu1QXK4gHcK745jxNW0whfTzMvfp793dvwIVJXdnk+2nP4kQPmB4FyIWsU/FZi1ZNcHJ 86mwT8/JAf922ON6HDpKtFXGSSqda0lqplXBG80TInEjmhsGo1/4SCPbGI92EJc3gpiJ 3pcD6Xv9Ig+n7/PTmvUOrFB95u8A9VRSRDgcpjeRPdss/7h7+3G4gK/uImC3PF/aSYM4 rqTw== X-Gm-Message-State: AOPr4FW7+kIXhW8pfUrIoPKPh2ewA4rjUicTDp2Kp42mSL2zlxBM/uJegeAxmAX+NRqPqA== X-Received: by 10.194.112.233 with SMTP id it9mr13062343wjb.22.1463090515850; Thu, 12 May 2016 15:01:55 -0700 (PDT) Original-Received: from [192.168.1.2] ([185.105.175.24]) by smtp.googlemail.com with ESMTPSA id gk4sm15333773wjd.7.2016.05.12.15.01.54 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 12 May 2016 15:01:54 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1 In-Reply-To: <87eg97hu2s.fsf@mail.linkov.net> 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:118190 Archived-At: On 05/12/2016 11:57 PM, Juri Linkov wrote: > So I see your aim is to use regexp replacements without regexps, > i.e. with only a list of region boundaries like is used by > region-noncontiguous-p in perform-replace. This may sound crazy, but shouldn't just using region-extract-function to return the list of region bounds work? FROM-STRING can then be `.*' without a problem. > I guess this could be > achieved with more hacking in real-match-data (maybe to use a layer > like replace-match-data). A lot code in perform-replace is really beyond my comprehension, but why would the undo code muck around with replaying match data? It could just as well repeat the searches.