From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.devel Subject: Re: A better UI than perform-replace Date: Fri, 20 Nov 2015 02:40:11 +0200 Organization: LINKOV.NET Message-ID: <87d1v5ttc4.fsf@mail.linkov.net> References: <56480D6C.2080408@yandex.ru> <876112xj2i.fsf@gmail.com> <87vb90yum7.fsf@mail.linkov.net> <564C6FD4.6090706@yandex.ru> <87a8qaiz5g.fsf@mail.linkov.net> <564D22F3.3080608@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1447980322 28344 80.91.229.3 (20 Nov 2015 00:45:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 20 Nov 2015 00:45:22 +0000 (UTC) Cc: Oleh Krehel , emacs-devel To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 20 01:45:12 2015 Return-path: Envelope-to: ged-emacs-devel@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 1ZzZp8-0001oe-Er for ged-emacs-devel@m.gmane.org; Fri, 20 Nov 2015 01:45:10 +0100 Original-Received: from localhost ([::1]:44797 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZzZp7-0007Rq-OQ for ged-emacs-devel@m.gmane.org; Thu, 19 Nov 2015 19:45:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54976) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZzZp4-0007Qv-Nj for emacs-devel@gnu.org; Thu, 19 Nov 2015 19:45:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZzZp1-00010e-IO for emacs-devel@gnu.org; Thu, 19 Nov 2015 19:45:06 -0500 Original-Received: from hapkido.dreamhost.com ([66.33.216.122]:59549) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZzZp1-0000zL-De for emacs-devel@gnu.org; Thu, 19 Nov 2015 19:45:03 -0500 Original-Received: from homiemail-a76.g.dreamhost.com (sub3.mail.dreamhost.com [69.163.253.7]) by hapkido.dreamhost.com (Postfix) with ESMTP id 2C87686F49 for ; Thu, 19 Nov 2015 16:45:02 -0800 (PST) Original-Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id 73C7A45807C; Thu, 19 Nov 2015 16:44:58 -0800 (PST) Original-Received: from localhost.linkov.net (82.131.20.219.cable.starman.ee [82.131.20.219]) (Authenticated sender: jurta@jurta.org) by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPA id 648DD45807B; Thu, 19 Nov 2015 16:44:57 -0800 (PST) In-Reply-To: <564D22F3.3080608@yandex.ru> (Dmitry Gutov's message of "Thu, 19 Nov 2015 03:16:35 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (x86_64-pc-linux-gnu) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 66.33.216.122 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:194841 Archived-At: >> I think we need to keep both the current multi-file query-replace and >> multi-occur, and extend the latter with query-replace capabilities, >> (thus a better mode name would be 'occur-query-replace-mode') because >> the current multi-file query-replace is already used in several places >> such as tags-query-replace. Then for xref you could take any of them. > > Yes, we'll need a separate occur-??? query-replace function that takes > a set of files as an argument. > > It would be cool if both query-replace functions had the same calling > convention, and we could choose the user-preferred one based on > a global variable. > >> PS: I noticed a FIXME in xref--query-replace-1, and I wonder why can't you >> use `multi-query-replace-map' the same way as it's used in tags-query-replace? > > Last time I tried, it wasn't a drop-in replacement: with > `multi-query-replace-map', `perform-replace' really expects to be called > once per buffer, and it would've been really inconvenient in the initial > implementation. Less so with the current one, though. Then instead of tags-loop-continue/next-file currently used by etags.el, we could have a much simpler function multi-query-replace with bufs arg.