From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.bugs Subject: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason Date: Sun, 31 Jan 2016 01:43:59 +0200 Organization: LINKOV.NET Message-ID: <87si1etyyo.fsf@mail.linkov.net> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1454199444 26366 80.91.229.3 (31 Jan 2016 00:17:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 31 Jan 2016 00:17:24 +0000 (UTC) Cc: 20489@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Jan 31 01:17:15 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 1aPfha-0004bx-Bs for geb-bug-gnu-emacs@m.gmane.org; Sun, 31 Jan 2016 01:17:14 +0100 Original-Received: from localhost ([::1]:40150 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aPfhZ-00057S-L3 for geb-bug-gnu-emacs@m.gmane.org; Sat, 30 Jan 2016 19:17:13 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46231) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aPfhU-00055T-Ax for bug-gnu-emacs@gnu.org; Sat, 30 Jan 2016 19:17:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aPfhO-0003YA-33 for bug-gnu-emacs@gnu.org; Sat, 30 Jan 2016 19:17:08 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:54187) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aPfhO-0003Y4-0c for bug-gnu-emacs@gnu.org; Sat, 30 Jan 2016 19:17:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aPfhN-0002LY-OG for bug-gnu-emacs@gnu.org; Sat, 30 Jan 2016 19:17:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 31 Jan 2016 00:17: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.14541993728932 (code B ref 20489); Sun, 31 Jan 2016 00:17:01 +0000 Original-Received: (at 20489) by debbugs.gnu.org; 31 Jan 2016 00:16:12 +0000 Original-Received: from localhost ([127.0.0.1]:42401 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aPfga-0002K0-9T for submit@debbugs.gnu.org; Sat, 30 Jan 2016 19:16:12 -0500 Original-Received: from sub3.mail.dreamhost.com ([69.163.253.7]:37942 helo=homiemail-a11.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aPfgY-0002Jq-AM for 20489@debbugs.gnu.org; Sat, 30 Jan 2016 19:16:10 -0500 Original-Received: from homiemail-a11.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a11.g.dreamhost.com (Postfix) with ESMTP id 9CE3F6E070; Sat, 30 Jan 2016 16:16:07 -0800 (PST) Original-Received: from localhost.linkov.net (62.65.226.255.cable.starman.ee [62.65.226.255]) (Authenticated sender: jurta@jurta.org) by homiemail-a11.g.dreamhost.com (Postfix) with ESMTPA id D25DA6E06A; Sat, 30 Jan 2016 16:16:06 -0800 (PST) In-Reply-To: <56AC0A95.2030001@yandex.ru> (Dmitry Gutov's message of "Sat, 30 Jan 2016 03:57:57 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (x86_64-pc-linux-gnu) 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:112116 Archived-At: >>> No: http://lists.gnu.org/archive/html/emacs-devel/2016-01/msg01286.html >>> >>> See the first sentence there. >> >> I reread it every time you reference it, but it adds nothing to the discussion. >> Could you provide more details about this problem. I imagine you meant the case >> when *xref* is hidden, but *compilation* is visible. Is it so? What are the >> preconditions for this situation to occur? > > You really should ask Eli what exactly he meant there, I'm just > guessing. I didn't want to keep inquiring at that point. Eli said disable, > so I disabled. I believe Eli meant this case because it's hard to imagine another one. So we have to find a solution for this case. By setting a window-local value of next-error-last-buffer in the selected window, we can continue the xref-navigation even when *compilation* is visible in an adjacent window. > But IMHO, (eq (length window-buffers) 1) is counter-intuitive: take the > configuration with three buffers with next-error-function set visible. Hide > the current last-buffer: nothing changes, `next-error' continues working as > it did. Hide the next one: and suddenly, `next-error' starts > behaving differently. When the number of next-error-function windows is more than one, then there's a dilemma which one to use. >> This is why I proposed to use window-local values, and your counter-arguments >> against it (indication/switching) apply to the already used global value >> of next-error-last-buffer as well: its current state is not discoverable >> and it's not easy to switch to another navigation. > > Your proposal _complicates_ the current state, making it more of > a problem. If the global value of next-error-last-buffer is used > consistently, at least the current state is easier to remember. But it allows the user to continue a paused navigation in another window in another frame, thus having several simultaneously active navigations in different windows. > The actual problem is that `next-error' exhibits surprising behavior, > and doesn't properly support `next-error-function' being set in > file-visiting buffers, which is a common situation these days. What happens when two features set `next-error-function' at the same time? I guess the latest wins, so there is no problem no matter if using visibility of next-error-last-buffer or window-local values. > Since filing this bug, I've somewhat warmed up to using buffer visibility > as a condition to choose next-error-last-buffer. Visibility of next-error-last-buffer is not suitable for navigations without a navigational buffer.