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: Thu, 21 Jan 2016 19:07:53 +0200 Message-ID: <83r3ha97yu.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> <83si1sa47q.fsf@gnu.org> <56A06965.7050501@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1453396081 28920 80.91.229.3 (21 Jan 2016 17:08:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 21 Jan 2016 17:08:01 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 21 18:07:56 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 1aMIi6-0006MM-MV for ged-emacs-devel@m.gmane.org; Thu, 21 Jan 2016 18:07:50 +0100 Original-Received: from localhost ([::1]:48987 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aMIi5-0006Lu-U9 for ged-emacs-devel@m.gmane.org; Thu, 21 Jan 2016 12:07:49 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48956) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aMIhy-0006LC-Js for emacs-devel@gnu.org; Thu, 21 Jan 2016 12:07:47 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aMIhv-00035k-Dr for emacs-devel@gnu.org; Thu, 21 Jan 2016 12:07:42 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:48515) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aMIhv-00035e-A5; Thu, 21 Jan 2016 12:07:39 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4414 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aMIhu-0005bP-Md; Thu, 21 Jan 2016 12:07:39 -0500 In-reply-to: <56A06965.7050501@yandex.ru> (message from Dmitry Gutov on Thu, 21 Jan 2016 08:15:17 +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:198504 Archived-At: > Cc: emacs-devel@gnu.org > From: Dmitry Gutov > Date: Thu, 21 Jan 2016 08:15:17 +0300 > > > 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). > > I never thought that the *xref* buffer is important for > dired-find-regexp-and-replace, and even considered creating a modified > version of xref-query-replace that wouldn't require that buffer. But > indeed, it seems important for continuing the replace operation. I think having the *xref* buffer visible is _the_ reason we could get rid of tags-loop-continue. > > 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. > > I think we can do something like this: as the user agrees to > replacements, we disable/mark/hide corresponding entries in the xref buffer. > > So if the user aborts the replace process, the *xref* buffer only > contains the entries they haven't gotten around to. (Or the skipped ones > too? That might be harder to implement). No, I think all the matches that the user saw already, whether she accepted the replacement or not, should be marked in some way, so that continuing the replacement goes to the first unseen one. > > 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. > > We've obsoleted find-tag and friends, though. Yes, but that was long ago, while these two commands are going to be replaced just now. Besides, they are Dired commands, not etags commands. So I think it does make a difference. In any case, this is not a terribly important point, it's easy to obsolete and it's also easy to unobsolete later if we change our minds. We can defer the decision for later. Thanks.