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: Thu, 28 Jan 2016 02:28:01 +0300 Message-ID: <56A95281.9080205@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> 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 1453944185 7654 80.91.229.3 (28 Jan 2016 01:23:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 28 Jan 2016 01:23:05 +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 Thu Jan 28 00:29:21 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 1aOZWR-0002oa-Be for geb-bug-gnu-emacs@m.gmane.org; Thu, 28 Jan 2016 00:29:11 +0100 Original-Received: from localhost ([::1]:53046 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aOZWQ-0008D7-JJ for geb-bug-gnu-emacs@m.gmane.org; Wed, 27 Jan 2016 18:29:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34116) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aOZWN-0008Cp-PZ for bug-gnu-emacs@gnu.org; Wed, 27 Jan 2016 18:29:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aOZWI-0002ZY-OZ for bug-gnu-emacs@gnu.org; Wed, 27 Jan 2016 18:29:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:50820) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aOZWI-0002ZR-KU for bug-gnu-emacs@gnu.org; Wed, 27 Jan 2016 18:29:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aOZWI-00009x-Ay for bug-gnu-emacs@gnu.org; Wed, 27 Jan 2016 18:29:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 27 Jan 2016 23:29:02 +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.1453937291553 (code B ref 20489); Wed, 27 Jan 2016 23:29:02 +0000 Original-Received: (at 20489) by debbugs.gnu.org; 27 Jan 2016 23:28:11 +0000 Original-Received: from localhost ([127.0.0.1]:39040 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aOZVS-00008r-N4 for submit@debbugs.gnu.org; Wed, 27 Jan 2016 18:28:10 -0500 Original-Received: from mail-lb0-f173.google.com ([209.85.217.173]:33632) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aOZVR-00008e-6p for 20489@debbugs.gnu.org; Wed, 27 Jan 2016 18:28:09 -0500 Original-Received: by mail-lb0-f173.google.com with SMTP id x4so14494375lbm.0 for <20489@debbugs.gnu.org>; Wed, 27 Jan 2016 15:28:09 -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=janw2B1geLU8UW4xbyIWeAfWm6HLCDqijYb6fjDOyKY=; b=W9ndxz8KDF9OHaXc0HLtxGnU1IcCatnMQJNFsj2nM59qhUw8HX5D9AIGPm6JfrZibN 5nbYTm3/lE/8CODVr6QoEuZatkDwBf/+soEhp9jhPkZCE7ZuQxSzaeVEzepDbaoXNf98 BLW7c/ayZXzU4ooQbeAyfmRhXSGvvZGZBpmK9G+JilHCqDSxr+xSd+wqF6q0TLNIcHbr Fs+gcKcOjo5mcQlQPHRGVlv0ZH4B1QT2oO7RWey5GCP0FPFTVL2WJEKfjitVQjR/wfcv rGB0MX+V6EESrbSKch46UPNHPLAToidRThVXTnha5D2QHUzl/MlOGuRzwtZ/8tLYsNe5 EFJg== 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=janw2B1geLU8UW4xbyIWeAfWm6HLCDqijYb6fjDOyKY=; b=DOLB+yVj/8gw5yL06wwyShFlWkCvWJPBof3SzBz/1h06puoaC59LYJGt2w6LGHWvR6 OwRGt+51powdVjbYdFJcxgabr4L5Oz17i2YNM+HFEyk6fGikJQPoYoYKJjMeiusn25jv qSrfzrMueaxErqgbnF7cFE+xXoHAsFsYg3n+pT+kPUwzWPJTJcZxlOtLW7B8bY/kWYcf marCCZr/+tXl/Dy+UxK8vLVxztUQzQsVd55FV1g4nm33ePkpRQdkdxEM5I3R9Pf7Qflu GCIlXyQS0r5LgN2Mck0fEB1LaoiO7I3QNI0je9BRLyxrtbHtKrXMLetxum9nbYh1gk9K lr3A== X-Gm-Message-State: AG10YOQpoYqZ7X5P7LreWTSON9020g09cj5y+3h1sp3uynMwTsQlZ+Dt29fO7+P/BV55GQ== X-Received: by 10.112.134.70 with SMTP id pi6mr9991798lbb.59.1453937283391; Wed, 27 Jan 2016 15:28:03 -0800 (PST) Original-Received: from [192.168.1.190] ([178.252.127.222]) by smtp.googlemail.com with ESMTPSA id 67sm907796lfq.36.2016.01.27.15.28.02 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Jan 2016 15:28:02 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Thunderbird/44.0 In-Reply-To: <87powmd410.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:112045 On 01/28/2016 01:57 AM, Juri Linkov wrote: > You can see an arrow indication in the left fringe of the navigational window > that points to the location of the current file displayed in an adjacent window. That's only true of compilation-mode and its derivatives. It's not a part of next-error-function contract (again, change-log-next-error does nothing of the sort; diff-next-error doesn't either). Maybe it's a good idea, but I'm not sure how to enforce something like that, to be able to rely on it. And a small arrow in one window is not a great indicator anyway. > I just posted an IDE-like layout to emacs-devel, and it demonstrates that the > current rule#1 in next-error-find-buffer is the right thing to do in this > scenario: after switching from e.g. *grep* to *xref* in the bottom window, > next-error will continue navigation from the visible navigation buffer. > So no changes are required in this case. What case? We're not going to introduce IDE-like layout as the mandatory, or the default, behavior. The rule#1, as written, also poorly interacts with Flycheck-like use cases. Are you going to comment on that part discussion? Because if you're going to disregard it, we might as well stop talking right now: any acceptable proposal, as far as I'm concerned, handles that case. > The problem is in the cases that this rule doesn't support, i.e. > (< (length window-buffers) 1) and (> (length window-buffers) 1) > We need to find a way to handle these cases as well. Yes: remove that check, for example. We can also realize that the rule #1 is an attempt to do the following: if next-error-last-buffer is no longer visible, try to pick a navigational buffer among the currently visible ones. However, the rule tries to limit the number of visible navigational buffer to one, and aborts otherwise. I think that's because it doesn't know any better way to distinguish between navigational buffers and plain file-visiting buffers that have next-error-function set locally (navigational buffers can also be file-visiting, as in the cases of change-log-mode and diff-mode). The new variable that I proposed would help. > No clicking at all, I don't use the mouse :) Lots of pressing the buttons, then. Which is what I meant.