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: Tue, 26 Jan 2016 02:36:17 +0300 Message-ID: <56A6B171.7080504@yandex.ru> References: <86wq0q602w.fsf@yandex.ru> <87oacaiszd.fsf@mail.linkov.net> <56A5BF79.909@yandex.ru> <87zivtqq81.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 1453765047 23602 80.91.229.3 (25 Jan 2016 23:37:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 25 Jan 2016 23:37:27 +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 Tue Jan 26 00:37:16 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 1aNqh3-00083b-Rx for geb-bug-gnu-emacs@m.gmane.org; Tue, 26 Jan 2016 00:37:10 +0100 Original-Received: from localhost ([::1]:41313 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aNqh2-0002Qp-SY for geb-bug-gnu-emacs@m.gmane.org; Mon, 25 Jan 2016 18:37:08 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47381) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aNqgz-0002QW-39 for bug-gnu-emacs@gnu.org; Mon, 25 Jan 2016 18:37:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aNqgw-00040p-BB for bug-gnu-emacs@gnu.org; Mon, 25 Jan 2016 18:37:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:48250) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aNqgw-00040l-6L for bug-gnu-emacs@gnu.org; Mon, 25 Jan 2016 18:37:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aNqgv-0000Co-Ld for bug-gnu-emacs@gnu.org; Mon, 25 Jan 2016 18:37:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 25 Jan 2016 23:37: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.1453764986746 (code B ref 20489); Mon, 25 Jan 2016 23:37:01 +0000 Original-Received: (at 20489) by debbugs.gnu.org; 25 Jan 2016 23:36:26 +0000 Original-Received: from localhost ([127.0.0.1]:36470 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aNqgM-0000Bx-B8 for submit@debbugs.gnu.org; Mon, 25 Jan 2016 18:36:26 -0500 Original-Received: from mail-lb0-f172.google.com ([209.85.217.172]:35411) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aNqgK-0000Bk-UX for 20489@debbugs.gnu.org; Mon, 25 Jan 2016 18:36:25 -0500 Original-Received: by mail-lb0-f172.google.com with SMTP id bc4so82920133lbc.2 for <20489@debbugs.gnu.org>; Mon, 25 Jan 2016 15:36:24 -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=rXfze5KOA6HVwiHNFdujUNK5fiAauK91bo3e9JP4/Y4=; b=OuPOAkEC0FQbTxaAlIByqpx0qEUKKl53+lQ2iG0ufwByJ2e5k7kB+S5DoTgYL8jxyI myEHM2PrNxdPlM0J8BE0hsoS/4pRnzWbVfC6TmcmV+jBKT+gAAF/52lN+Sy2ZzCvjbkK TwW6tQsChGE2bomMqYTvWO90EMp+/25vs1ofTD3wpsgqhNI/qOb1VoczlVj1VbGsPr5B X9LxpSur9tnz8Pu1RQcUrzaemsqz1SDXUnI8oHss1inYtaRVE9A3Dg6fo3B9RFzrzV2I o0KVWo9dOMdHWgLdQ0QITyTFgswjq3B/w5TRxiNfP13gaqGFwV/Ki/4+DG4ZBI1zfpx4 fC5Q== 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=rXfze5KOA6HVwiHNFdujUNK5fiAauK91bo3e9JP4/Y4=; b=gVJ+XgrFmCpWMnh1NuC3poaR7ToQZDqWM8iSMoAxO5/JQ6fHRpf2Bj10linzHGz3A3 eNYepPXDXr62QFHwj8/0gZxkY5XTdduHkjZQF6Reox/HhWguj9/MwXeVdXEiOMDCv2sr mhiCnhAcokNR4i9tVjF8QwYMw5K1fI+OKg2tzoLuJoUvMofdo1/d4t0M00f4pS+oeV1C psjkf9SQyl+b6dloZX6HiNKk/SYNnhAMfKIGp6VZjyULQl85DQ7Bpo9xy/OqDO2eznVA p0n1DMSkp0CZ0P3Z8M8cZQPHww1rRJKujEg/6ZUlOIF5Hy8MoNJ3rqRJG5BYERyH2BH5 D/hA== X-Gm-Message-State: AG10YOTP9Nh6p5FYOeE5MxtIbnG+fnCFEFzJGsU0emWId9qaIwg2+UXAC5+P9+4L+29kKA== X-Received: by 10.112.143.68 with SMTP id sc4mr7225454lbb.122.1453764979102; Mon, 25 Jan 2016 15:36:19 -0800 (PST) Original-Received: from [192.168.1.190] ([178.252.127.222]) by smtp.googlemail.com with ESMTPSA id r63sm3129865lfe.38.2016.01.25.15.36.17 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Jan 2016 15:36:17 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Thunderbird/44.0 In-Reply-To: <87zivtqq81.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:111971 Archived-At: On 01/26/2016 12:55 AM, Juri Linkov wrote: > A frame might contain more pairs of navigational/target windows, > e.g. a window with *grep* output, and a file buffer visited from *grep*; > a window with *Occur*, and another place in the same file buffer > but visited from *Occur*, etc. Yes, but it wasn't your scenario there. In that scenario, you switched to a different frame, which had only a *compilation* buffer visible, and were surprised to see a next-error-function used from a non-visible buffer you last accessed in a different frame. > So frame-local is not of help here, whereas window-local is, > provided a navigational window (like *grep*/*compilation*) > always displays target buffers in another dedicated window. How does it really help? You've navigated from *grep*, to that buffer A, then did that from *compilation*, and then you can't continue jumping to next *grep* occurrences from that buffer. frame-local could be sufficient if we were sure that different navigation windows show error locations in distinctly different sets of windows, IMHO. 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. > As I see this is not what xref currently does: navigating in it > jumps between many different windows that is very inconvenient, > but this can be easily fixed to work the sane way as *grep* > or *compilation* already works. Yes, this can use an improvement. >> How do linting minor modes (like Flycheck or Flymake) fit into this? > > Does Flycheck or Flymake display a navigation window with a list of results? Flycheck has such a buffer, but it's not displayed by default. And in any case, it sets next-error-function locally in file buffers, but not in its "list of errors" buffer. Hmm. Apparently, Flymake doesn't set next-error-function, so we can disregard it. js2-mode is another example: it's a major mode that sets next-error-function in its buffers. You can ask it for the "list of errors" buffer as well, but it's usually not shown. > If not, then this is a new case that we need to support as well. Apparently so. >> Suppose I called M-x compile (or, better yet, M-x grep), navigated to some >> file buffer from it and then see that it has some linter errors highlighed >> by Flycheck. So I want to use the current buffer's next-error-function now, >> and jump between linter warnings using next/previous-error. How do I do >> that? IIU your plan correctly, the current window-local >> next-error-last-buffer value will continue pointing at the Grep buffer, >> even if I bury it. > > What if you have two navigations in the same buffer, and both are > without a navigation window that you can't bury? I don't follow. The above was an attempt to point out an hole in your plan. I'm not sure you can refute that with a "what if" counter-example. >> - Some indicator that a given buffer's next-error-function points to other >> buffer (then, if you're in a different buffer, that other buffer is still >> relevant). Like a buffer-local variable called, for example, >> next-error-function-nonlocal. > > Do you mean to bind a navigation buffer with navigated target buffers/windows? 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. >> - A command (or several) to switch between the plausible candidates for >> next-error-last-buffer. Maybe just have a single command that uses >> read-buffer with a predicate checking the aforementioned variable and an >> extra option that means "just use the current buffer". > > This would be too complicated to use. 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. The main point, however, which you might not agree with, is to make next-error-last-buffer global. >> - Ignore next-error-last-buffer's visibility. Or make it frame-local, to >> account for your scenario as well (but that would bring extra complexity: >> some people use use frames like almost separate applications, and other can >> use frames instead of windows, and display them side-by-side). > > Buffers are displayed in windows, so better to bind them to windows. 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. > I remember the original idea was to always continue the same navigation > that displayed a given target buffer/window, so switching to another > navigation in the same window could be achieved by explicitly navigating > to another result from another navigation, e.g. when current navigation > was from *compilation* then switching to *grep* buffer and typing M-n > for the next grep hit in the same file buffer. How will you "switch" to the next-error-function set locally by Flycheck in the current file-visiting buffer? 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? Using a command to switch between next-error-last-buffer candidates seems much quicker.