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:02:26 +0200 Message-ID: <83si1q987x.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> <56A0659F.1010306@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1453395748 23283 80.91.229.3 (21 Jan 2016 17:02:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 21 Jan 2016 17:02:28 +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:02:23 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 1aMIco-0003bO-RF for ged-emacs-devel@m.gmane.org; Thu, 21 Jan 2016 18:02:22 +0100 Original-Received: from localhost ([::1]:48926 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aMIcn-0004GP-LW for ged-emacs-devel@m.gmane.org; Thu, 21 Jan 2016 12:02:21 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47326) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aMIci-0004Dg-Ch for emacs-devel@gnu.org; Thu, 21 Jan 2016 12:02:17 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aMIcf-0001jK-6U for emacs-devel@gnu.org; Thu, 21 Jan 2016 12:02:16 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:48418) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aMIcf-0001jF-3k; Thu, 21 Jan 2016 12:02:13 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4410 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aMIce-00065a-EW; Thu, 21 Jan 2016 12:02:12 -0500 In-reply-to: <56A0659F.1010306@yandex.ru> (message from Dmitry Gutov on Thu, 21 Jan 2016 07:59:11 +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:198503 Archived-At: > Cc: emacs-devel@gnu.org > From: Dmitry Gutov > Date: Thu, 21 Jan 2016 07:59:11 +0300 > > On 01/20/2016 02:19 PM, Eli Zaretskii wrote: > > > 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. > > Or repeat the search. After the repeating it enough times, the user > might start to remember the name of the buffer. Repeating the search was precisely what I did. But that's not exactly user-friendly, I think. > > You cannot continue the search without > > switching back to *xref* first. > > You mean with `next-error'? When so, it's simply a bug in next-error. Using next-error never occurred to me (there's nothing about that in NEWS or in the manual). Yes, that works. But it has the problem you mentioned in a past discussion: if you have (say) a Grep buffer from a recent search, it's not easy to tell next-error which of them to use. I guess the feature you suggested back then for making this easier never materialized? Maybe we should introduce it now. > > 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. > > Let's say I agree. What shall we do with xref-find-definitions? Should > the user understand somehow that in this case RET won't bury the buffer, > and in xref-find-definitions' case, it wont? > > I suppose we could provide a separate key (`a'?) that would do what RET > does now. Maybe we should make RET do the same as '.' in all cases, and provide a separate key to delete the window showing *xref*. WDYT?