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: Sun, 31 Jan 2016 03:39:35 +0300 Message-ID: <56AD57C7.5050809@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> 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 1454200823 14754 80.91.229.3 (31 Jan 2016 00:40:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 31 Jan 2016 00:40:23 +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 Sun Jan 31 01:40:12 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 1aPg3m-0006tD-V4 for geb-bug-gnu-emacs@m.gmane.org; Sun, 31 Jan 2016 01:40:11 +0100 Original-Received: from localhost ([::1]:40171 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aPg3l-0000h7-JR for geb-bug-gnu-emacs@m.gmane.org; Sat, 30 Jan 2016 19:40:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50071) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aPg3h-0000fo-8I for bug-gnu-emacs@gnu.org; Sat, 30 Jan 2016 19:40:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aPg3e-0008KO-3Y for bug-gnu-emacs@gnu.org; Sat, 30 Jan 2016 19:40:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:54193) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aPg3d-0008KH-VM for bug-gnu-emacs@gnu.org; Sat, 30 Jan 2016 19:40:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aPg3d-0002tP-N7 for bug-gnu-emacs@gnu.org; Sat, 30 Jan 2016 19:40: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: Sun, 31 Jan 2016 00:40: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.145420078511090 (code B ref 20489); Sun, 31 Jan 2016 00:40:01 +0000 Original-Received: (at 20489) by debbugs.gnu.org; 31 Jan 2016 00:39:45 +0000 Original-Received: from localhost ([127.0.0.1]:42413 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aPg3M-0002so-NR for submit@debbugs.gnu.org; Sat, 30 Jan 2016 19:39:44 -0500 Original-Received: from mail-lf0-f51.google.com ([209.85.215.51]:33846) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aPg3L-0002sZ-3W for 20489@debbugs.gnu.org; Sat, 30 Jan 2016 19:39:43 -0500 Original-Received: by mail-lf0-f51.google.com with SMTP id j78so7345403lfb.1 for <20489@debbugs.gnu.org>; Sat, 30 Jan 2016 16:39:42 -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=Zo+/ixLbc+HMlH9uGOgr+hPixdvr+y8wE9eP4inYnyo=; b=NBqDyRLlE1sxC9xg/aLGsmJxLV9lCzzsTL9wG/Jc5vzL3z6zh6jYcPO4NfNsuPcOPY gXy9n209j56DkWoa/FM2Rc8HEkmpUzrxrO5fXN/faxyJ/j5z57tQiBUUmsdGzSzoUUn5 PhrWYZvxfYuHMtr9nUGA7aeyK5DxeOzGogDmP3MXdjqgF00aMok1XK2h3nxWRjukFwxK IbKGc69vWHetSys3lTlsFKLWVnkAii1tFp6Qr9o2J2UCjdjdN2LOzVF9qH6SP3SuMS1q HSmRtXEfX9gz9XbDxgC4I1XHzVV8CNGfDdTDKNsVwjelrptHfa6sohhrfyBWN+iIEwiI qELQ== 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=Zo+/ixLbc+HMlH9uGOgr+hPixdvr+y8wE9eP4inYnyo=; b=Wy3xPOmvXziBBTxHyAq1LMplf3n2/uUgvBj9F0abDKRhoctVkfJFFwbjwX+4o77V0+ nRPM1Px8low49hJQRJKXaG+bz8Dc8xpAyebI5tSkMBYj9/pHHkMSPW8DcqL8TcPIVEy1 Q6FXbqZlOlG1o7UzdCBPb8mHOyUo2OpTKnOxIqAs6giLYM3k01TxWvADGgAAKiqt7K91 B4765fEAT6zgJh+nR2Z41NAIiml4iPaVQ9nsSkxu7mfDTl+reUsRyu++2cO2F4SRF5pt lmseSnVa1Af6DCuT5CGh4KBjSzjPxqlDpbndjB657rlND7MhEK1NH0uGRWHCa+YShCfa hd3Q== X-Gm-Message-State: AG10YOSA5jS8NftrgQu1KXeedTi7xRTTIWf9ibQ9oF7Ui1Z1r0VDEJoMNNoUSzeDMPMxiw== X-Received: by 10.25.135.198 with SMTP id j189mr3498639lfd.84.1454200777318; Sat, 30 Jan 2016 16:39:37 -0800 (PST) Original-Received: from [192.168.1.190] ([178.252.127.222]) by smtp.googlemail.com with ESMTPSA id f4sm2918386lbs.10.2016.01.30.16.39.36 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 30 Jan 2016 16:39:36 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Thunderbird/44.0 In-Reply-To: <87si1etyyo.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:112119 Archived-At: On 01/31/2016 02:43 AM, Juri Linkov wrote: > I believe Eli meant this case because it's hard to imagine another one. > So we have to find a solution for this case. Let's not base the rest of the discussion on a guess, shall we? In the message above, he was replying to my message, where I said: "On the other hand, while *xref* is visible, `next-error' will keep working for its results". I can hardly imagine that in his counter-example, *xref* is hidden. > By setting a window-local value of next-error-last-buffer in the > selected window, we can continue the xref-navigation even when > *compilation* is visible in an adjacent window. Yes. But we _only_ continue it from the same window, which I do not believe to be a good goal. On the other hand, if we just use the global next-error-last-buffer value, we'll just as well "continue the xref-navigation even when *compilation* is visivle in an adjacent window". >> But IMHO, (eq (length window-buffers) 1) is counter-intuitive: take the >> configuration with three buffers with next-error-function set visible. Hide >> the current last-buffer: nothing changes, `next-error' continues working as >> it did. Hide the next one: and suddenly, `next-error' starts >> behaving differently. > > When the number of next-error-function windows is more than one, then > there's a dilemma which one to use. Let's use the last one. That would definitely simplify things. On the other hand, if we assign and read next-error-last-buffer value via two accessor functions, anyone would be able to change the locality of that value. You'd be able to use advice, to store it window-locally. >> Your proposal _complicates_ the current state, making it more of >> a problem. If the global value of next-error-last-buffer is used >> consistently, at least the current state is easier to remember. > > But it allows the user to continue a paused navigation in another window > in another frame, thus having several simultaneously active navigations > in different windows. If the "previous" navigation buffer is visible, you can also continue navigation by going to it, and using one of the links there. If it's not visible, it would make remembering which window belongs to which navigation, even more difficult. > What happens when two features set `next-error-function' at the same time? > I guess the latest wins, so there is no problem no matter if using > visibility of next-error-last-buffer or window-local values. Yes, if next-error-function is set locally in a file buffer, we can only see the last value. But rather than "no problem", I'd say that neither approach to visibility of next-error-last-buffer solves the Flycheck problem. >> Since filing this bug, I've somewhat warmed up to using buffer visibility >> as a condition to choose next-error-last-buffer. > > Visibility of next-error-last-buffer is not suitable for navigations > without a navigational buffer. Hence my proposal to equate the value nil of next-error-last-buffer with "use the current buffer".