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: Fri, 22 Jan 2016 16:08:17 +0200 Message-ID: <837fj17lm6.fsf@gnu.org> References: <83wprimto9.fsf@gnu.org> <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> <83si1q987x.fsf@gnu.org> <56A11160.2010309@yandex.ru> <83k2n2964e.fsf@gnu.org> <56A12A4B.7030609@yandex.ru> <838u3i92n1.fsf@gnu.org> <56A12D6D.7080504@yandex.ru> <837fj29057.fsf@gnu.org> <56A13C75.4030606@yandex.ru> <83zivy7jq5.fsf@gnu.org> <56A14B00.1090207@yandex.ru> <56A14D05.7070807@yandex.ru> <83y4bi6qws.fsf@gnu.org> <56A200C0.1010309@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1453471709 9503 80.91.229.3 (22 Jan 2016 14:08:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 22 Jan 2016 14:08:29 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 22 15:08:25 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 1aMcO0-0001Xl-RQ for ged-emacs-devel@m.gmane.org; Fri, 22 Jan 2016 15:08:25 +0100 Original-Received: from localhost ([::1]:54077 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aMcNw-0007uh-N9 for ged-emacs-devel@m.gmane.org; Fri, 22 Jan 2016 09:08:20 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56321) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aMcNk-0007uZ-AF for emacs-devel@gnu.org; Fri, 22 Jan 2016 09:08:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aMcNf-0007Sl-I3 for emacs-devel@gnu.org; Fri, 22 Jan 2016 09:08:08 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:51038) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aMcNf-0007Sg-FQ; Fri, 22 Jan 2016 09:08:03 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1232 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aMcNb-0005z4-QI; Fri, 22 Jan 2016 09:08:00 -0500 In-reply-to: <56A200C0.1010309@yandex.ru> (message from Dmitry Gutov on Fri, 22 Jan 2016 13:13:20 +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:198579 Archived-At: > Cc: emacs-devel@gnu.org > From: Dmitry Gutov > Date: Fri, 22 Jan 2016 13:13:20 +0300 > > On 01/22/2016 09:59 AM, Eli Zaretskii wrote: > > >> And if someone asks for it back, ask them to go fix bug#20489 first. > > > > I was about to suggest this myself. So yes, let's do that. If we > > indeed try harder to leave the *xref* buffer visible, the need for > > this integration would be lower. > > On the other hand, while *xref* is visible, `next-error' will keep > working for its results (it's item 1 in next-error-find-buffer). > > That's how `next-error' stayed useful for e.g. *compilation* all these > years. And it's fairly handy to call `next-error' to go to the next > result, without having to switch back to *compilation*. The problem is not with *compilation* alone or with *xref* alone, the problem happens when you have both of them. > So, do we really remove the integration? Up to you. I think removing it will leave us with a lesser evil. Maybe leaving that code commented out with a reference to bug#20489 would increase the discoverability of the problem, and we could have a solution sooner, I don't know. We could also have a defcustom (to enable this in *xref*), but that sounds too much, no? Thanks.