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: Sat, 30 Jan 2016 03:57:57 +0300 Message-ID: <56AC0A95.2030001@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> 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 1454115572 15938 80.91.229.3 (30 Jan 2016 00:59:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 30 Jan 2016 00:59:32 +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 Sat Jan 30 01:59: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 1aPJsh-0005Vd-Vu for geb-bug-gnu-emacs@m.gmane.org; Sat, 30 Jan 2016 01:59:16 +0100 Original-Received: from localhost ([::1]:37165 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aPJse-0002TF-D4 for geb-bug-gnu-emacs@m.gmane.org; Fri, 29 Jan 2016 19:59:12 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52408) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aPJsZ-0002T5-W2 for bug-gnu-emacs@gnu.org; Fri, 29 Jan 2016 19:59:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aPJsU-0005pd-UL for bug-gnu-emacs@gnu.org; Fri, 29 Jan 2016 19:59:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:52657) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aPJsU-0005pS-Qg for bug-gnu-emacs@gnu.org; Fri, 29 Jan 2016 19:59:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aPJsU-0004XJ-GB for bug-gnu-emacs@gnu.org; Fri, 29 Jan 2016 19:59: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: Sat, 30 Jan 2016 00:59: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.145411548817374 (code B ref 20489); Sat, 30 Jan 2016 00:59:02 +0000 Original-Received: (at 20489) by debbugs.gnu.org; 30 Jan 2016 00:58:08 +0000 Original-Received: from localhost ([127.0.0.1]:40877 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aPJrb-0004WA-L7 for submit@debbugs.gnu.org; Fri, 29 Jan 2016 19:58:07 -0500 Original-Received: from mail-lf0-f52.google.com ([209.85.215.52]:34397) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aPJrZ-0004Vg-Su for 20489@debbugs.gnu.org; Fri, 29 Jan 2016 19:58:06 -0500 Original-Received: by mail-lf0-f52.google.com with SMTP id 17so56934465lfz.1 for <20489@debbugs.gnu.org>; Fri, 29 Jan 2016 16:58:05 -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=3PSRBdhgF3E1j1wGneGGhqKpksrkn2LKQrMvFtDgTdc=; b=feUwRRVy53PyzL9aHzDXhG5F4No4y72WNDu7jmFR35y6/jXW4fBDCHc3ItxvKqAvLt CMODuWHHivyG0h89mtjIzoWEOV/aJcpSyUwOhFU/tKjEVoOCLIlflu30los9AXckuFat cdqu6Dqx8AN2T3tqaOTUnYRB6ER5EjvsPE25TC3+6tqlbzI+ae8yfSogcSM0+jDZ9RMu Lc9UdwJOagnGWWaGKsFasGy5MqrXfVAYPJo0g4ACVKLnsqoaExKCBulgu/JuLQzftHCM brtYgKU38/7i330vYagAojNoc8k7+mr6E1+aeqJ7BKwKXxNXjve8zol9lA8Ww9kO01Gg bVoQ== 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=3PSRBdhgF3E1j1wGneGGhqKpksrkn2LKQrMvFtDgTdc=; b=biuCIlmeXN6UAsTyVQE59SAxuOwnLbKbyUn3kpG9wVe/SbfXGAxVWmIZcJNQWVqxWS EaeKjNqBOjDI+a68ECpTBrh+nn7ec/rnpvfI3E6si+4jJJ2xmgo+Zri58/U+WhSHGDfi zlhsw3CD6ZJw1dBYjZe4UQa2SVmd6aYnDhySVQgftxorR6vN9WWcQZUCieMxoFXaVlzA KaFe7GZENBa/R1y5D0KUFeQIZJzbUK1CcTzRbMJpGFishUA2d285rbEGB0nL6o952D60 Ph4brFZfhn9h8ZssEO4IDd9PNjmwJ6S5d2bfi/jmdAv9kotC0s02u+GEhkX+8mE6Fquv D9sw== X-Gm-Message-State: AG10YOSA6Bj/10KeBOSdyEmseqT9CFT8JS1xkIRxGfD8wqQYUcMLGKFV6Upx8IQjb8SaEQ== X-Received: by 10.25.90.83 with SMTP id o80mr4426294lfb.23.1454115479828; Fri, 29 Jan 2016 16:57:59 -0800 (PST) Original-Received: from [192.168.1.190] ([178.252.127.222]) by smtp.googlemail.com with ESMTPSA id c192sm2489030lfb.16.2016.01.29.16.57.58 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 29 Jan 2016 16:57:58 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Thunderbird/44.0 In-Reply-To: <871t90c5o8.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:112091 Archived-At: On 01/30/2016 02:44 AM, Juri Linkov wrote: > Not repeatedly, it's enough to type is only once, and subsequent invocations > of next-error will pick up a new navigation. Fair enough. But the complaint about memorizing different key bindings still stands. >>> A real problem is when a navigational buffer does exist, but it's hidden. >>> IIUC, due to this problem you reverted next-error integration in xref, right? Why is that a problem? Depending on the approach, we either keep using it, or switch to the visible one. >> No: http://lists.gnu.org/archive/html/emacs-devel/2016-01/msg01286.html >> >> See the first sentence there. > > I reread it every time you reference it, but it adds nothing to the discussion. > Could you provide more details about this problem. I imagine you meant the case > when *xref* is hidden, but *compilation* is visible. Is it so? What are the > preconditions for this situation to occur? You really should ask Eli what exactly he meant there, I'm just guessing. I didn't want to keep inquiring at that point. Eli said disable, so I disabled. 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. The user is expected to understand too much. >> When *multi-occur* jumps to *compilation*, next-error-last-buffer keeps >> referring to *multi-occur*. > > But after you hide *compilation*, *multi-occur* will kick in. So? It's you who's advocating to stop using the non-visible last-buffer's. My first choice is to only switch next-error-last-buffer when the user requests this explicitly. On the other hand, if we choose the semantics "not visible => bad last-buffer", that would be understandable, too. I don't see why you consider the case "multi-occur references compilation" to be more special than others. It seems no different from "both grep and compilation are visible". > This is why I proposed to use window-local values, and your counter-arguments > against it (indication/switching) apply to the already used global value > of next-error-last-buffer as well: its current state is not discoverable > and it's not easy to switch to another navigation. 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. I'm also not a big fan of window-local semantics here, personally. > This issue is real, > but orthogonal to the subject of bug#20489. Would you like me to rename the subject to something? The actual problem is that `next-error' exhibits surprising behavior, and doesn't properly support `next-error-function' being set in file-visiting buffers, which is a common situation these days. Since filing this bug, I've somewhat warmed up to using buffer visibility as a condition to choose next-error-last-buffer.