From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: tags-loop-continue Date: Wed, 20 Jan 2016 13:19:05 +0200 Message-ID: <83si1sa47q.fsf@gnu.org> References: <83wprimto9.fsf@gnu.org> <56916C10.6050004@yandex.ru> <83oacumqmj.fsf@gnu.org> <56917246.1010800@yandex.ru> <5691795E.9010008@yandex.ru> <83lh7ym725.fsf@gnu.org> <5691D768.3020908@yandex.ru> <83bn8tmnvq.fsf@gnu.org> <56928356.2000609@yandex.ru> <8360z1mkfc.fsf@gnu.org> <5696EE9D.2090708@yandex.ru> <838u3si22k.fsf@gnu.org> <5697C7A8.6060601@yandex.ru> <83wprcgjxk.fsf@gnu.org> <5697DA3B.3070706@yandex.ru> <83io2wggh8.fsf@gnu.org> <5697EC73.6040302@yandex.ru> <83fuy0gf2j.fsf@gnu.org> <5697F3C9.5040702@yandex.ru> <83bn8ogd8c.fsf@gnu.org> <56980073.7050604@yandex.ru> <838u3rhpzk.fsf@gnu.org> <569D3ADC.5060803@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1453288872 6477 80.91.229.3 (20 Jan 2016 11:21:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 20 Jan 2016 11:21:12 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jan 20 12:20:54 2016 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 1aLqon-0007zB-My for ged-emacs-devel@m.gmane.org; Wed, 20 Jan 2016 12:20:53 +0100 Original-Received: from localhost ([::1]:42109 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLqom-0004Vv-Qt for ged-emacs-devel@m.gmane.org; Wed, 20 Jan 2016 06:20:52 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54644) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLqo0-00047y-0n for emacs-devel@gnu.org; Wed, 20 Jan 2016 06:20:49 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aLqms-0001PG-Ci for emacs-devel@gnu.org; Wed, 20 Jan 2016 06:20:03 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:50789) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLqms-0001P7-7c; Wed, 20 Jan 2016 06:18:54 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2854 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aLqmr-0006pW-Jt; Wed, 20 Jan 2016 06:18:53 -0500 In-reply-to: <569D3ADC.5060803@yandex.ru> (message from Dmitry Gutov on Mon, 18 Jan 2016 22:19:56 +0300) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:198426 Archived-At: > Cc: emacs-devel@gnu.org > From: Dmitry Gutov > Date: Mon, 18 Jan 2016 22:19:56 +0300 > > On 01/14/2016 11:21 PM, Eli Zaretskii wrote: > > A new command, I think. One step at a time. > > > It should be dired-do-SOMETHING, for consistency with others. > > > Or maybe have a minor variant bound to 'Q' that would also ask for a > > replacement, like query-replace? > > Added both commands. Please check them out. Thanks, I took a look at the two commands. They look good overall, IMO, but I have a few comments. First, they both take a long time to display the first match. I understand that's because you run Grep to collect all the matches, but can't you let Grep run asynchronously, display the first match as soon as it comes in, and then update the list as the rest arrive? You don't need to present the matches in any particular order, so it sounds like waiting for all of them is not required. I think this initial delay will be quite long in large directories (I tried with Emacs's 'src' directory, which is not very large, and my disk is SSD, but it still took annoyingly long). I'm guessing we will get a lot of complains from users of these two commands who were accustomed to a much faster startup. My other problem is with the "disappearing *xref* buffer" phenomenon: it is too easy to lose it, and not so easy to get it back. With 'A' (dired-do-find-regexp) it's enough to type RET on a line in the *xref* buffer in order to have its window deleted; the only way to get it back AFAICT is to manually switch to that buffer, which means the user must remember its name. You cannot continue the search without switching back to *xref* first. So I think RET should not delete the window in this case. Maybe it should never delete the window, in other users of xref, I'm not sure. At least in this case, unlike with xref-find-definition, it is much more probable that the user _will_ want to go to the next match, so it makes less sense IMO to delete the window. With 'Q' (dired-find-regexp-and-replace) losing *xref* is a lot easier: as you walk through the matches, the window which displayed *xref* suddenly switches to display one of the files with matches instead of showing *xref*. I think that window should not be reused for showing matches (perhaps through some display-buffer magic). Even worse, there seems to be no way of continuing with the query-replace operation once it is interrupted for some reason. It happened to me when I tried to resize the window (because I wanted to see less of the *xref* buffer) -- Emacs exited the query-replace command, and I couldn't find a way to continue it where I left off, even after switching to the *xref* buffer. I think there should be a way, perhaps with '.' and/or RET, to continue the query-replace from the match on the current line in *xref*, otherwise people will complain. > If they're considered good enough, I think we can re-obsolete > tags-loop-continue, and obsolete dired-do-search and > dired-do-query-replace-regexp as well. I wouldn't obsolete them just yet. We may wish letting users who will be unhappy with the new UI to have a way to get the old behavior back, until the new UI is improved enough to satisfy users. But we can certainly document the new commands instead of the old ones in the manual. Thanks.