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: Wed, 27 Jan 2016 05:43:26 +0300 Message-ID: <56A82ECE.6050609@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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1453862662 2541 80.91.229.3 (27 Jan 2016 02:44:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 27 Jan 2016 02:44: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 Wed Jan 27 03:44: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 1aOG5a-0000xa-EQ for geb-bug-gnu-emacs@m.gmane.org; Wed, 27 Jan 2016 03:44:10 +0100 Original-Received: from localhost ([::1]:47856 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aOG5Z-0003zs-NJ for geb-bug-gnu-emacs@m.gmane.org; Tue, 26 Jan 2016 21:44:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52321) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aOG5W-0003zn-1M for bug-gnu-emacs@gnu.org; Tue, 26 Jan 2016 21:44:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aOG5S-0003MZ-QV for bug-gnu-emacs@gnu.org; Tue, 26 Jan 2016 21:44:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:49778) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aOG5S-0003MU-Ll for bug-gnu-emacs@gnu.org; Tue, 26 Jan 2016 21:44:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aOG5S-0000wa-Gw for bug-gnu-emacs@gnu.org; Tue, 26 Jan 2016 21:44: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 02:44: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.14538626153589 (code B ref 20489); Wed, 27 Jan 2016 02:44:02 +0000 Original-Received: (at 20489) by debbugs.gnu.org; 27 Jan 2016 02:43:35 +0000 Original-Received: from localhost ([127.0.0.1]:37998 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aOG51-0000vp-CO for submit@debbugs.gnu.org; Tue, 26 Jan 2016 21:43:35 -0500 Original-Received: from mail-lf0-f41.google.com ([209.85.215.41]:36672) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aOG4z-0000va-NP for 20489@debbugs.gnu.org; Tue, 26 Jan 2016 21:43:34 -0500 Original-Received: by mail-lf0-f41.google.com with SMTP id h129so118847835lfh.3 for <20489@debbugs.gnu.org>; Tue, 26 Jan 2016 18:43:33 -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=3DjwlrUm661h8330gSHJlXnlAEBSIGAHv7YhHQ8mmgk=; b=zTSiY8YPQW6BuSbCKbm0fgfgsZMbhDzt3DshiAaPXA95CsIwuWgs0+I97XYZRs1bE+ tHdG13nXg80MaLQpwDvmWsTQ+pjWRrqag1aELI5akvzqzbbAZnmq8zSX3uYy8Fe7zCN9 zYweJu1T4VO0+Dmncn8/VbNCO9i49/OqNDTymyElwfSzIDNLZUJW0lb2yxvICgvD67Bz uqcUQK6e5JtoRHdNUQNBSIZNQMEoAT1ZJyhrBZjDhxJXHJBUm0BcCRJiaOzklhSCEqM1 Hl8mdzYGoLkobkE4sJZ6bsG5RTRj9j3/G03PS0BLU+aM2aqnVN7nxcfXJLed62kwcHMC 1ghg== 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=3DjwlrUm661h8330gSHJlXnlAEBSIGAHv7YhHQ8mmgk=; b=m+SWC3w6Pz1vTAhPmgxIVNCJIlmdw9lw71xLDymKIJHgTyNKh3al3T3L4Ww0EQ6oTz mxq3ixAsfdDXjG28EoaZuYwcYQFZ9VE1q4rkmAdIwtYEZO7gNV0M1je/x6YoGmhsQpmE qCyewrVdb4jEuscIfkIRtRyR2iaxvFjaR/hS6CgARO9QAxfxAsJ0TnUw80a1I31WZagB vGyEGKm8LGRMqGbt7bMVjpRZJ7fPy6wZ/TMZORYLJsqJiinZ8LX0CVEMoRQo+8DGbmSV icP8GGv2BToKxZA8V6Sm4fxFfoJqQy+Z1lyLNEagygxbX26j4AO58t2vgo6Jmw8T9fwa 22YQ== X-Gm-Message-State: AG10YOQaUiglfaxgwXVic20R7N2NILMiBcUBHeGKlxQPHu4DQJzv/HZ5zkio+M+NbZU+UQ== X-Received: by 10.25.152.199 with SMTP id a190mr10701911lfe.133.1453862607783; Tue, 26 Jan 2016 18:43:27 -0800 (PST) Original-Received: from [192.168.1.190] ([178.252.127.222]) by smtp.googlemail.com with ESMTPSA id f186sm512310lfd.26.2016.01.26.18.43.26 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Jan 2016 18:43:26 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Thunderbird/44.0 In-Reply-To: <87y4bbol9h.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:112022 Archived-At: On 01/27/2016 03:57 AM, Juri Linkov wrote: > I suppose that navigation from every navigational window displays its targets > in own dedicated window that will be associated with its “parent” window. That's a considerable change. Associated how? The window itself won't have any indication with which navigation buffer it's associated with, will it? And what if you do have the same buffer references in different navigation windows? Will they have to show it in both associated windows? That seems wasteful. > So e.g. after navigating from *grep* to window A, and from *compilation* > to window B, next-error invoked from windows A or B will continue > the right navigation. Suppose you've did that, then turned left to look out of the window for half a minute, then looked back at Emacs. How are you going to predict what M-x next-error will do? Now, in addition to remembering which navigational command you ran last, you have to remember the window associations. >> We can fix xref, but not every next-error-function uses the same window, >> and that's not codified in this variable's docstring. change-log-next-error >> doesn't. > > If some next-error-function doesn't use the same window, still there is > no problem because its displayed window will continue the last navigation > visited in that window. And soon, all windows in the frame will refer to the ChangeLog buffer as its next-error-last-buffer, right? `next-error' always continuing the last navigation does not require window-local values. We can just have next-error-last-buffer to be global. And if you're still thinking of the two-frame scenario, here's a little modification: - Run M-x grep in one frame, with several windows, jump to an error there, in window A. - Switch to another frame, run M-x compile there. - Switch back to the first frame. But select some other window than A. Call M-x next-error, and see it use the location from the *compilation* buffer, even though *grep* is visible right there. That scenario looks just as counter-intuitive to me as the original one. Your proposal would only fix the original one. > This adds another problematic case to consider, but we could avoid it > by always requiring creation of a navigation buffer, possibly hidden > when necessary. (As for your point about a hole, I already addressed it > below - that requires unburing a navigation buffer that you want switch to). One navigational buffer per file buffer? That's too much. >> I mean to ask compilation-mode (as well as other similar modes) to >> (setq-local next-error-function-nonlocal t), in addition to setting >> next-error-function and next-error-last-buffer. > > How this could help to point to other buffer? It will only tag it to be available for completion in the new pick-next-error-last-buffer command. Or we can put those buffers in a ring, which was also suggested here previously. That would also tag them, and allow switching between them in a historical fashion. >> Why complicated? It would just be a way to choose the source of errors to >> follow. You'd also be able to do that by clicking on an error, or pressing >> RET, in the "nonlocal" navigation buffers. > > I think it would be more WYSIWYG first to switch to the navigation buffer, > and then to click on an error, or press RET. That can also be a way to change the global next-error-last-buffer value. And whether it's window-local or not, neither scenario solves the Flycheck problem. >> The main point, however, which you might not agree with, is to make >> next-error-last-buffer global. > > I prefer this precedence: > 1. window-local next-error-last-buffer > 2. buffer-local next-error-last-buffer > 3. global next-error-last-buffer My preference is: 3, 2. Except we never set next-error-last-buffer locally, so we should interpret the global nil value to mean "the current buffer". >> Making next-error-last-buffer window-local feels clunkier to me: there >> would be no indication that a given window is following *Compilation*, for >> example. And up until now, next-error worked more or less in >> a global fashion. > > Are you hinting that currently there is such indication in the form of > navigation buffer's window displayed in the same frame (rule#1 in > next-error-find-buffer)? That an one option - we can indeed keep some logic reliant on whether next-error-last-buffer is visible in the current frame (but drop the "not more than one" limitation, because it leads to non-intuitive behavior). Then the change to the API could be smaller, but the use case of using next-error with non-visible navigational buffers will be more broken than currently. But my first choice is to not rely on buffer visibility at all, and simply follow the current global next-error-last-buffer value, as well as provide an easy way to switch to a different one. > I proposed window-local next-error-last-buffer only because you had > some problems with this rule using in xref. Yes, I did. But IIUC, Eli had more of a problem with the (if (eq (length window-buffers) 1) part of that rule. The commit that disabled next-error integration in xref has a link to that discussion in its message. >> How will you "switch" to the next-error-function set locally by Flycheck in >> the current file-visiting buffer? > > By restarting Flycheck? Restarting how? It's a minor mode that triggers linting checks when the buffer is saved, or you've typed something and wait a bit, or the file buffer has just been opened. The exact set of conditions is customizable. And it doesn't set next-error-last-buffer at all. But suppose it did. Imagine: you M-x compile, jump to an error, that opens the file in a new buffer, Flycheck kicks in, runs its linting check, and sets next-error-function and next-error-last-buffer in that buffer. If you call next-error now, you'll be jumping to the next linting error, not *compilation* error. >> How will you switch between Grep and Compilation if they display a location >> in the same buffer (and window)? Won't the desired navigation buffer have >> to be visible? So you'd have to select some window, switch to that buffer >> in it, and then click or press RET on some error? > > Yes. Lots of clicking. >> Using a command to switch between next-error-last-buffer candidates seems >> much quicker. > > In case of Flycheck, there will be no next-error-last-buffer, no? We should interpret nil as "use the current buffer".