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: Sat, 30 Jan 2016 01:44:07 +0200 Organization: LINKOV.NET Message-ID: <871t90c5o8.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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1454111436 20270 80.91.229.3 (29 Jan 2016 23:50:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 29 Jan 2016 23:50:36 +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 Sat Jan 30 00:50:26 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 1aPInx-0007Yj-9y for geb-bug-gnu-emacs@m.gmane.org; Sat, 30 Jan 2016 00:50:17 +0100 Original-Received: from localhost ([::1]:37040 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aPInw-0001uh-Q5 for geb-bug-gnu-emacs@m.gmane.org; Fri, 29 Jan 2016 18:50:16 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47706) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aPInk-0001gQ-Ha for bug-gnu-emacs@gnu.org; Fri, 29 Jan 2016 18:50:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aPIni-0002CR-R6 for bug-gnu-emacs@gnu.org; Fri, 29 Jan 2016 18:50:04 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:52651) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aPIni-0002Bx-NC for bug-gnu-emacs@gnu.org; Fri, 29 Jan 2016 18:50:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aPIni-0002vt-0Y for bug-gnu-emacs@gnu.org; Fri, 29 Jan 2016 18:50:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 29 Jan 2016 23:50: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.145411138011235 (code B ref 20489); Fri, 29 Jan 2016 23:50:01 +0000 Original-Received: (at 20489) by debbugs.gnu.org; 29 Jan 2016 23:49:40 +0000 Original-Received: from localhost ([127.0.0.1]:40871 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aPInM-0002v9-Bh for submit@debbugs.gnu.org; Fri, 29 Jan 2016 18:49:40 -0500 Original-Received: from sub3.mail.dreamhost.com ([69.163.253.7]:45018 helo=homiemail-a22.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aPInL-0002v2-4k for 20489@debbugs.gnu.org; Fri, 29 Jan 2016 18:49:39 -0500 Original-Received: from homiemail-a22.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a22.g.dreamhost.com (Postfix) with ESMTP id 9289B1A8071; Fri, 29 Jan 2016 15:49:36 -0800 (PST) Original-Received: from localhost.linkov.net (62.65.213.148.cable.starman.ee [62.65.213.148]) (Authenticated sender: jurta@jurta.org) by homiemail-a22.g.dreamhost.com (Postfix) with ESMTPA id C21E01A8061; Fri, 29 Jan 2016 15:49:35 -0800 (PST) In-Reply-To: <56AAB3C7.70902@yandex.ru> (Dmitry Gutov's message of "Fri, 29 Jan 2016 03:35:19 +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:112090 Archived-At: > Do you expect me to repeatedly type `C-c ! n' to move across errors in the > current buffer? It's not like it's inconvenient or > anything. next-error-function was added exactly so that the user doesn't > have to learn a bunch of different key bindings for basically the > same thing. Not repeatedly, it's enough to type is only once, and subsequent invocations of next-error will pick up a new navigation. >> A real problem is when a navigational buffer does exist, but it's hidden. >> IIUC, due to this problem you reverted next-error integration in xref, right? > > 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? >> Yes, this is because it's hard to find a better way, and I'm not sure >> how next-error-function-nonlocal could help, because sometimes a navigation >> might visit another non-file navigational buffer, e.g. multi-occur >> visiting a *compilation* buffer. > > What is the exact problem you have in mind there? > > When *multi-occur* jumps to *compilation*, next-error-last-buffer keeps > referring to *multi-occur*. But after you hide *compilation*, *multi-occur* will kick in. 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. This issue is real, but orthogonal to the subject of bug#20489.