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: Sun, 15 May 2016 00:13:15 +0300 Message-ID: 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> <783855a4-8ac2-f53c-7722-eacf530d732c@yandex.ru> <87shxkz7yu.fsf@mail.linkov.net> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1463260481 5477 80.91.229.3 (14 May 2016 21:14:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 14 May 2016 21:14:41 +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 Sat May 14 23:14:29 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 1b1gtE-0000Pl-Be for geb-bug-gnu-emacs@m.gmane.org; Sat, 14 May 2016 23:14:24 +0200 Original-Received: from localhost ([::1]:38921 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b1gtA-0008CS-Es for geb-bug-gnu-emacs@m.gmane.org; Sat, 14 May 2016 17:14:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46710) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b1gt6-000860-Sz for bug-gnu-emacs@gnu.org; Sat, 14 May 2016 17:14:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b1gt1-0006ir-Q1 for bug-gnu-emacs@gnu.org; Sat, 14 May 2016 17:14:15 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:39420) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b1gss-0006hr-MK for bug-gnu-emacs@gnu.org; Sat, 14 May 2016 17:14:11 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1b1gss-00084N-DZ for bug-gnu-emacs@gnu.org; Sat, 14 May 2016 17:14: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: Sat, 14 May 2016 21:14: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.146326040530964 (code B ref 23484); Sat, 14 May 2016 21:14:02 +0000 Original-Received: (at 23484) by debbugs.gnu.org; 14 May 2016 21:13:25 +0000 Original-Received: from localhost ([127.0.0.1]:51757 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1b1gsH-00083M-Gt for submit@debbugs.gnu.org; Sat, 14 May 2016 17:13:25 -0400 Original-Received: from mail-wm0-f41.google.com ([74.125.82.41]:37421) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1b1gsF-000839-9P for 23484@debbugs.gnu.org; Sat, 14 May 2016 17:13:23 -0400 Original-Received: by mail-wm0-f41.google.com with SMTP id a17so79886168wme.0 for <23484@debbugs.gnu.org>; Sat, 14 May 2016 14:13:23 -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=pNEV4ngxEgSUMwxDbD/n10EXMe5syfUxeurbmC4jrnA=; b=yf9fvLoAbbmoWdcbfuwGF9vA44OUdJcgO/1a6MpqnBI30PR/yPP1dh3iRb1+G5+I+k G6iGHbOiuqn9CMZPyV8EjX0/Ch6O9Mrtjj46AkWprlZ7+MHBB2KROqkYUnk91oz4dsPE VJWIwh3ycP4X5Ht3ff+HvFq5qXSBTdRSuRtyO0TKOsWfbhN2/X1+N5VxVmti01AJUGJ7 nytoGuvnyrRMZLkflba7ceQgaroz1Zwe+TPvsB4Mpmvqi3DYHLUZcqnk6mOpGxgMcKhS L1AqDROPvGgbX4xfmsmIsljqG1sQycU0ToRJ+x/1uT7svOiMyXTjlNrdymXg6/eRtPWc iAgg== 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=pNEV4ngxEgSUMwxDbD/n10EXMe5syfUxeurbmC4jrnA=; b=V5flh6rsLAz06OQesJFPBieNgWwLcFdDoelNgPGKkM+5tdrKzSzCZQD/+Bgznm3JVr ECbS62zZruppFH5AvaWTcVPT2m/s7bxp5Wf+EXdiGu6ltN0o05xBVz91iWwieuujruSp Rp42yOhsgyvZK/mElH02x8M91Go4T3juawj9jqY1sC+zIl7K14cxRHFTTj5IBKlif5EP QGAWeAuOH+UjOP7aZXxVTbR+mz6V4i85X9wJK4iHGM4lSlDtBYJYNW67Iop9pMy/nllU VOAGr7kSHxn3pUGbYYOLcsW+hq+ECKLTJYiVODjciwTlTK3BSBuWiu2Vouq81N/Yn7h4 IQDA== X-Gm-Message-State: AOPr4FXUT5JfZkKvRq3k8lZt84Uud6eN6g/mW9SXcPmARGKlinqtZqZViqPTKJq1ps4Hmw== X-Received: by 10.194.175.168 with SMTP id cb8mr22236326wjc.56.1463260397620; Sat, 14 May 2016 14:13:17 -0700 (PDT) Original-Received: from [192.168.1.2] ([185.105.175.24]) by smtp.googlemail.com with ESMTPSA id ry15sm25434704wjb.19.2016.05.14.14.13.16 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 14 May 2016 14:13:16 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1 In-Reply-To: <87shxkz7yu.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:118248 Archived-At: On 05/14/2016 11:34 PM, Juri Linkov wrote: > By default .* tries to match whole lines. If you have a rectangular region, shouldn't replacing .* with whatever only touch the parts of each line within that rectangle? That's what region-noncontiguous-p means. > For partial matches you need > to use a combination of goto-line and BOUND arg of re-search-forward. Either you are referring to the current implementation of xref--query-replace-1, or I don't know what else you want me to do. > But I still don't see a case where a search regexp used to find matches > in the *xref* buffer can't be re-used in xref-query-replace-in-results. I have mentioned xref-find-references several times in the recent messages alone. An like I said, several times, an xref backend is allowed to implement it with something more complex than using a plain regexp search. In fact, if the current directory has a CScope or Global index generated, and the relevant program is installed, xref-collect-references *will* use something different than a regexp search. > I tried ‘xref-find-definitions’ with a string identifier, then typed ‘r’ > > Then I thought that maybe you meant the case of ‘xref-find-apropos’ Replacing the results of xref-find-definitions or xref-find-apropos would be a useless nonsense (all usages of the function(s) or variable(s) in question would be left intact). This is one of a few reasons why it isn't supported. > It's difficult to find a solution without a real use case. If my explanations are too complicated, can't you just take it on faith that the only data the replacement command can use here is a list of pairs of markers? > Maybe undo could use a search function too. And with using > a search function should also avoid the need to disable > query-replace-lazy-highlight in xref--query-replace-1. Not sure how one follows from the other, but great. > But it seems there is no hurry in fixing undo because undo of replacements > is a new feature existing only in master, not in the release branch. Sure. I never implied that this bug is a blocker for 25.1. > If you are looking for a solution for the next release, I recommend > to not expose .* in the minibuffer to the users - that causes too many > problems. Since one release will happen in the meantime, we'll probably hear about this from the users anyway. But this is orthogonal to the solution for the current problem. > Either leave the initial FROM regexp empty, so the user types > an explicit string, So they'll always *have to* type something? This is very impractical, which is definitely worse than just being confusing. > or don't ask FROM at all, ...and implicitly use `.*' as FROM. I think I've replied to this suggestion twice already. > using the same regexp > provided to find matches in the *xref* buffer, thus removing all tricks > with isearch-filter-predicate/replace-re-search-function, i.e. since the > .* replacement is not a release-ready feature, just continue its development > in master. FFS, no. This is not feasible.