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, 4 Feb 2016 04:00:10 +0300 Message-ID: <56B2A29A.3060407@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> <56AE8CF3.9030108@yandex.ru> <878u33ncr9.fsf@mail.linkov.net> <56B00903.7050706@yandex.ru> <87d1se62co.fsf@mail.linkov.net> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1454547682 23661 80.91.229.3 (4 Feb 2016 01:01:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 4 Feb 2016 01:01:22 +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 Feb 04 02:01:11 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 1aR8II-0001Ih-Cz for geb-bug-gnu-emacs@m.gmane.org; Thu, 04 Feb 2016 02:01:10 +0100 Original-Received: from localhost ([::1]:38755 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aR8IH-0000lm-HH for geb-bug-gnu-emacs@m.gmane.org; Wed, 03 Feb 2016 20:01:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43192) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aR8ID-0000le-Tu for bug-gnu-emacs@gnu.org; Wed, 03 Feb 2016 20:01:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aR8IA-0007aA-Ne for bug-gnu-emacs@gnu.org; Wed, 03 Feb 2016 20:01:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:49947) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aR8IA-0007a6-JK for bug-gnu-emacs@gnu.org; Wed, 03 Feb 2016 20:01:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aR8IA-0005Zz-9n for bug-gnu-emacs@gnu.org; Wed, 03 Feb 2016 20:01: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: Thu, 04 Feb 2016 01:01: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.145454761921390 (code B ref 20489); Thu, 04 Feb 2016 01:01:02 +0000 Original-Received: (at 20489) by debbugs.gnu.org; 4 Feb 2016 01:00:19 +0000 Original-Received: from localhost ([127.0.0.1]:58536 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aR8HT-0005Yw-8k for submit@debbugs.gnu.org; Wed, 03 Feb 2016 20:00:19 -0500 Original-Received: from mail-lf0-f46.google.com ([209.85.215.46]:35216) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aR8HR-0005Yf-QB for 20489@debbugs.gnu.org; Wed, 03 Feb 2016 20:00:18 -0500 Original-Received: by mail-lf0-f46.google.com with SMTP id l143so26021516lfe.2 for <20489@debbugs.gnu.org>; Wed, 03 Feb 2016 17:00:17 -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=9r5JRvm9anOP64LqDbzwL6A48ePoSP69V0FmM5EjEwU=; b=eN28ag5leasFAMsB3Tvs0w17KmAS55y52YDDcVbcPaSRwoZQw9MRNXmfeltGqpLB11 g84ktv7Qxk4tlZxFODpmzMZkDrGu1NODceiwbtF8PDAHSqM8c+7ySfUeERe6CfnmRBEq vKNwjhjPOKx5gfJlc9Y1CDGKjvFvxJJsjCKRFB2elVHlIhrlFo61i8F2rxReE8o1knxl j7jK4e6ZvxsF8a9yGg8HoJJLG3O9rHvl3C6G1bejFvlJtMAt8CIuFCrr/Q8j12t0Hl1T rPt4+KTvCgv1AgGUBg0K1XFoKas3m7JD+U3e4rij0BdowNzjc0y/zxddditq5aDmyTkp JkPA== 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=9r5JRvm9anOP64LqDbzwL6A48ePoSP69V0FmM5EjEwU=; b=TQBjoVmGK8z6c6AEGMVnTwISmt99JM9bienzvAhfKsW26AMDOuXGgIkml+X3gYPLwq oe2XyfwEE4r77Ura6VrJl7hF+5aJPjmt7p+tw9HDMocbga+FI+x4l0ekXbag6xg7VKSc GGU2JjG7dP0j3YOFHgQltgyP/i2m7j7/A68DfmQV4GLbiW3oA6G6jr3DeztQOYqiEtE5 EaeWSRAwTPT6pkO25kUUhLKNfAf3OsftdLrJ8uu7SR9IOEPjAjUUytRnsDdPIFQ5Xxfe Pj5T3tJhrjqtvju5DUU8718QQKo9MxO7/re1TtJt5Otjelb/2dP+Ng7WH6/RfS5LPGMZ BxAQ== X-Gm-Message-State: AG10YORZ+ZsIwRNXbCVSQIp5jnv0olrPJWSq8wtF74VYc+2ydsMCzcGZMm+Q8xKoJ4kOHA== X-Received: by 10.25.20.165 with SMTP id 37mr2174893lfu.53.1454547611711; Wed, 03 Feb 2016 17:00:11 -0800 (PST) Original-Received: from [192.168.1.190] ([178.252.127.222]) by smtp.googlemail.com with ESMTPSA id rd3sm1168842lbb.2.2016.02.03.17.00.10 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 03 Feb 2016 17:00:10 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Thunderbird/44.0 In-Reply-To: <87d1se62co.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:112361 Archived-At: On 02/03/2016 03:35 AM, Juri Linkov wrote: >> You're welcome to poll, but so far we only have the data about >> a single user. > > Yes, a single user who wants to remove it ;) Apparently, you have no data at all, then. As a user, I don't care about it either way. As a _developer_, I might remove it. Which is what should be done if a feature can't be implemented in a sane way without trampling on user experience in other aspects. > Just traverse all windows in the order of recency until finding a window > with next-error-function. This will almost always default to the current window if you write Elisp, and have global-flycheck-mode enabled. Can't you give a full, constructive proposal, instead of giving pieces that are easy to poke holes in? >>>> And, again, this ignores the Flycheck case. >>> >>> Alas, this means we have to trade visibility of next-error-last-buffer >>> for window-local values. >> >> What means? And why? > > In case of Flycheck it's next-error-last-buffer is the current buffer > and is always visible. You haven't answered the "what" question. But assuming I managed to guess your meaning... How come window-local values are any better? If "next-error-last-buffer is the current buffer" is the current buffer when the variable is stored globally, it will be the window-local value when the variable is stored window-locally. Unless the buffer is not visible, in which case the question is moot. >>>> 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? >>> >>> It will display foo.el in the window where bar.el previously was. >> >> Aren't you at all worried about running out of windows (and not being >> allowed to split them)? In our last discussion with Martin, he expressed >> concern that some users use one window per frame. In this scenario, you'll >> need at least 3. And with two navigational buffers visible, the number of >> necessary windows will grow to 5. > > I meant reusing an existing window with a file buffer, not creating a new > window. Then you are contradicting yourself. > I see no reason not to use this behavior by default. It undermines your proposal: either you have a separate dedicated window for each navigational buffer to show locations in, or the navigational buffers trample on each other's windows when they visit the same files. Which creates the same problem you had, except in certain specific circumstances. But those circumstances are not *that* rare. This will make the behavior less consistent and increase user confusion. > What I see is that *compilation* always reuses another window to not replace > the navigational *compilation* buffer with a file buffer. Do you know > under what circumstances this behavior might fail. *compilation* jumps to foo.el, then *grep* jumps to foo.el. Both use the same window (the default behavior), and both have an arrow in their buffers indicating that foo.el's window is "theirs". However, the last navigational buffer wins. >> Nonlocal next-error-functions represent groups of windows that are somehow >> related (parts of the same problem, matches for the same input, or so >> on). And with them, we can at least expect that the next error still might >> be in the current buffer. > > This is why I proposed window-local variables to bind a group of windows > to their parent navigational window. I don't see how that solves anything.