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, 03 May 2015 02:17:43 +0300 Message-ID: <86wq0q602w.fsf@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1430608762 27779 80.91.229.3 (2 May 2015 23:19:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 2 May 2015 23:19:22 +0000 (UTC) To: 20489@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun May 03 01:19:11 2015 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 1Yoggg-0002Py-J3 for geb-bug-gnu-emacs@m.gmane.org; Sun, 03 May 2015 01:19:10 +0200 Original-Received: from localhost ([::1]:58087 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yoggf-0004fR-QO for geb-bug-gnu-emacs@m.gmane.org; Sat, 02 May 2015 19:19:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37026) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yoggc-0004fB-F0 for bug-gnu-emacs@gnu.org; Sat, 02 May 2015 19:19:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YoggY-0000nI-D4 for bug-gnu-emacs@gnu.org; Sat, 02 May 2015 19:19:06 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:50083) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YoggY-0000nD-9R for bug-gnu-emacs@gnu.org; Sat, 02 May 2015 19:19:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YoggX-0001ny-UM for bug-gnu-emacs@gnu.org; Sat, 02 May 2015 19:19:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 02 May 2015 23:19:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 20489 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.14306086906872 (code B ref -1); Sat, 02 May 2015 23:19:01 +0000 Original-Received: (at submit) by debbugs.gnu.org; 2 May 2015 23:18:10 +0000 Original-Received: from localhost ([127.0.0.1]:60058 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yogfh-0001mm-Vp for submit@debbugs.gnu.org; Sat, 02 May 2015 19:18:10 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:51560) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yogff-0001ma-UZ for submit@debbugs.gnu.org; Sat, 02 May 2015 19:18:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YogfZ-0000UG-ID for submit@debbugs.gnu.org; Sat, 02 May 2015 19:18:02 -0400 Original-Received: from lists.gnu.org ([2001:4830:134:3::11]:36546) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YogfZ-0000U7-GG for submit@debbugs.gnu.org; Sat, 02 May 2015 19:18:01 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36830) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YogfY-0004bX-Le for bug-gnu-emacs@gnu.org; Sat, 02 May 2015 19:18:01 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YogfU-0000K5-Kj for bug-gnu-emacs@gnu.org; Sat, 02 May 2015 19:18:00 -0400 Original-Received: from mail-wg0-x22f.google.com ([2a00:1450:400c:c00::22f]:34031) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YogfU-0000Ha-Da for bug-gnu-emacs@gnu.org; Sat, 02 May 2015 19:17:56 -0400 Original-Received: by wgso17 with SMTP id o17so119215947wgs.1 for ; Sat, 02 May 2015 16:17:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:subject:date:message-id:mime-version:content-type; bh=/pCNAXVAAiyKLJEqmEi1ia41yV2eTze1in9jagebGLQ=; b=pDecvlBa7jFCavBf7ME4aXk0Wvj5SR7A6DMxcgCtNyeEMmz3H1CCV1f7MeHZjI2KQo oGdkxdT5gzslPBqUiMcJSbJScGvLFRFaxBPbUWI+6ucn5d3OLJMTb7jQf3NJvzhQ6n1x 3NSCpVqX6QFMG+XtdbpcizildE6ZNmD+dF3jw2gV6oSpzb0lEvxKYtBzeyH9yFxjIMFp uTG7mXiZpMGl1tYM2fOtSprLcIOF+4YaBS8Ew3Hvla+rE+orZgRfdNKknebUWvZcH4TC BM297R7eHAZR9J7atTfxwUY11hJgjT1mfeBRH+wNoQwCKVK+E+hMFFrkGlFf1t/bLZYT fHjw== X-Received: by 10.180.216.103 with SMTP id op7mr7719042wic.90.1430608666975; Sat, 02 May 2015 16:17:46 -0700 (PDT) Original-Received: from axl ([82.102.93.54]) by mx.google.com with ESMTPSA id df1sm4232206wib.12.2015.05.02.16.17.46 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 02 May 2015 16:17:46 -0700 (PDT) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.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:102388 Archived-At: I've been trying to understand why when the current file-vising buffer has next-error-function set localy, sometimes `next-error' uses it, and sometimes it uses next-error-function from next-error-last-buffer. Looking at the current `next-error-find-buffer', the logic is this: - If a buffer visible in the current frame has next-error-function set, *and* if there's only one such buffer, use it. - If next-error-last-buffer has it set, use that. Othewise, if both of the above fail, - If the current buffer has next-error-function set, use it. That's nonsense. Why should the question of whether the current buffer's next-error-function is used be decided by whether there are any other visible buffers with that variable set. Apparently, this peculiarity has been there for 10.5 years now, introduced in 03e75c7e0 by Juri Linkov. But there's no bug reference, nor a link to a discussion. I'm guessing it was an attempt to solve a problem of next-error-last-buffer never being used if the current buffer has next-error-function. But I think the solution is worse than the problem. It least the previous behavior was consistent. In GNU Emacs 25.0.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.12.2) of 2015-05-02 on axl Windowing system distributor `The X.Org Foundation', version 11.0.11601901 System Description: Ubuntu 14.10