From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason Date: Mon, 1 Feb 2016 01:38:43 +0300 Message-ID: <56AE8CF3.9030108@yandex.ru> References: <86wq0q602w.fsf@yandex.ru> <87oacaiszd.fsf@mail.linkov.net> <56A5BF79.909@yandex.ru> <87zivtqq81.fsf@mail.linkov.net> <56A6B171.7080504@yandex.ru> <87y4bbol9h.fsf@mail.linkov.net> <56A82ECE.6050609@yandex.ru> <87powmd410.fsf@mail.linkov.net> <56A95281.9080205@yandex.ru> <8737th5kt6.fsf@mail.linkov.net> <56AAB3C7.70902@yandex.ru> <871t90c5o8.fsf@mail.linkov.net> <56AC0A95.2030001@yandex.ru> <87si1etyyo.fsf@mail.linkov.net> <56AD57C7.5050809@yandex.ru> <87egcxpg36.fsf@mail.linkov.net> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1454279964 5731 80.91.229.3 (31 Jan 2016 22:39:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 31 Jan 2016 22:39:24 +0000 (UTC) Cc: 20489@debbugs.gnu.org To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Jan 31 23:39:12 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1aQ0eF-0001Pd-So for geb-bug-gnu-emacs@m.gmane.org; Sun, 31 Jan 2016 23:39:12 +0100 Original-Received: from localhost ([::1]:43586 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aQ0eF-00027q-2c for geb-bug-gnu-emacs@m.gmane.org; Sun, 31 Jan 2016 17:39:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45838) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aQ0eB-00027l-9V for bug-gnu-emacs@gnu.org; Sun, 31 Jan 2016 17:39:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aQ0e6-0002jr-9c for bug-gnu-emacs@gnu.org; Sun, 31 Jan 2016 17:39:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:55358) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aQ0e6-0002jn-5g for bug-gnu-emacs@gnu.org; Sun, 31 Jan 2016 17:39:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aQ0e5-0008WQ-Uc for bug-gnu-emacs@gnu.org; Sun, 31 Jan 2016 17:39:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 31 Jan 2016 22:39:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20489 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 20489-submit@debbugs.gnu.org id=B20489.145427993332743 (code B ref 20489); Sun, 31 Jan 2016 22:39:01 +0000 Original-Received: (at 20489) by debbugs.gnu.org; 31 Jan 2016 22:38:53 +0000 Original-Received: from localhost ([127.0.0.1]:43578 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aQ0dw-0008W3-QQ for submit@debbugs.gnu.org; Sun, 31 Jan 2016 17:38:53 -0500 Original-Received: from mail-lb0-f169.google.com ([209.85.217.169]:35066) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aQ0dv-0008Vq-4U for 20489@debbugs.gnu.org; Sun, 31 Jan 2016 17:38:51 -0500 Original-Received: by mail-lb0-f169.google.com with SMTP id bc4so65399169lbc.2 for <20489@debbugs.gnu.org>; Sun, 31 Jan 2016 14:38:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=D4KfY8fXyrLnRWKx7kik43771rtdweU0BC7Qklszt0c=; b=crKPF5AhBKUUmaRjfwv9+fl0MSAmSTIxJXsBYNPdTjfhqFvsA2kKjmi2Y9IZkxOxga RrLk4/pB/FKCw0sMf4KHNkOaN0B0mUCkx+IbF15zJe2VpDIOclFUXXw0ZIO+zxS0wA9x H389mFVdNixLurmj8l938wHLMeOuglr4NWczaxJtEkKSzsnsGweoQLd/Ui7RO3G0RXdq X3AjXH6afS+qitiUQWaNgtSQwjE4q59WiF6HbotBwGRdT6jpda9N1NQijn917O3HZna5 BCYMZoIUz8witjTQx8EJjxZkfQQpompglbj3ZEDH38W2yW0GSwWHRJEnGZJOvcnhakva hf/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:to:references:cc:from:message-id :date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=D4KfY8fXyrLnRWKx7kik43771rtdweU0BC7Qklszt0c=; b=hig1Z4DPsdEOI90AzdGJJzXe3LtyuvcPHzgJ/Y1qVJiklr9zbzyPhloxkGPNwHXGdo BIlX1SfhSyqbO0ZQmGJ+4KiVMcztD5AzVBplkP4MX13EBG4EvqFHFs79VKfY6kMqubQo uCOZQ3Musri/GLkslZIRvVcHOgzpXtUjyF4xrWcN5u/O0myhEXohFgeKZc+RsX2urw3P XEAKncveRLzmCL/w87aDpqWPx9DWIhRGRMqJDr9t3fjWoJm26j/xspzbDKHlgsIRdDhY gWdQSk4hwRdAa++tAbLCBwcTJqLAwoU+dC39UImyAvZxJOSDDPrlvqoAHBQeadVS/ZO4 FKqQ== X-Gm-Message-State: AG10YOSNl5kUAZuUjGjgG8cNmmEx5EeVTK97sNQd2uPzaVJeCF4hFedf/5FSX/HYPqZY6w== X-Received: by 10.112.161.225 with SMTP id xv1mr7186063lbb.127.1454279925380; Sun, 31 Jan 2016 14:38:45 -0800 (PST) Original-Received: from [192.168.1.190] ([178.252.127.222]) by smtp.googlemail.com with ESMTPSA id l189sm3521600lfd.30.2016.01.31.14.38.43 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 31 Jan 2016 14:38:44 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Thunderbird/44.0 In-Reply-To: <87egcxpg36.fsf@mail.linkov.net> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:112167 Archived-At: On 02/01/2016 12:57 AM, Juri Linkov wrote: >> In the message above, he was replying to my message, where I said: "On the >> other hand, while *xref* is visible, `next-error' will keep working for its >> results". > > Clearly, this describes a successful case as opposed to the problematic one > where *xref* is hidden that evidently needs fixing. Yes. This was my appeal to keep the existing integration of xref with next-error-function. Eli disagreed. What can we gather from that? >> On the other hand, if we just use the global next-error-last-buffer value, >> we'll just as well "continue the xref-navigation even when *compilation* is >> visible in an adjacent window". > > And lose the support for the case of simultaneously active navigations > in different windows/frames. Yup. Did you have many requests, from different users, before introducing this support? >>> When the number of next-error-function windows is more than one, then >>> there's a dilemma which one to use. >> >> Let's use the last one. That would definitely simplify things. > > Indeed, using (get-mru-window 'visible t t) makes sense. I don't follow. The window returned by the above won't necessarily have next-error-function set. And, again, this ignores the Flycheck case. >> If the "previous" navigation buffer is visible, you can also continue >> navigation by going to it, and using one of the links there. >> >> If it's not visible, it would make remembering which window belongs to >> which navigation, even more difficult. > > Isn't it so that the user will remember which navigation displayed > a given window? Sorry, _what_ is so? > At least, with window-local values the Flycheck navigation in the given buffer > will be confined within the selected window and won't affect other navigations > in other windows. With your approach, no window will affect other windows. Even if I ran M-x rgrep, and I see its buffer in the current frame, I'll also have to remember which window it ended at. And if I never clicked on a link in the *grep* buffer, I can't use C-x ` in any window, I'm assuming. > So continuing a navigation in other buffers/windows won't > continue Flychecking of an unrelated buffer. So Flychecking should not set > the global value of next-error-last-buffer. Suppose I use flycheck-next-error in foo.el. And I have a *grep* buffer visible, and I jumped to bar.el from it. And the next error in *grep* is in foo.el. What happens when I, having returned to bar.el's window, call next-error again? Does it jump to foo.el's window? Does it display foo.el in the window where bar.el previously was? Does every navigational window get a second, dedicated window for its locations? Often, we don't have many windows to spare. >> Hence my proposal to equate the value nil of next-error-last-buffer with >> "use the current buffer". > > What/who and how would nullify/reset next-error-last-buffer? A new command. Or maybe a special value of the prefix argument to `next-error'? M-0 C-x `, maybe? But if we have a new command, I could also allow selecting from some of the existing buffers which contain "nonlocal" next-error-function's.