From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!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, 28 Feb 2018 04:13:54 +0200 Message-ID: References: <86wq0q602w.fsf@yandex.ru> <877ev36pmr.fsf@mail.linkov.net> <87sha1nbjy.fsf@mail.linkov.net> <23fd061a-9b83-742a-6083-6d2f090b8f22@yandex.ru> <81d36dbe-f563-187a-ec16-df4b051ae204@yandex.ru> <87efl6smxb.fsf@mail.linkov.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1519783994 27190 195.159.176.226 (28 Feb 2018 02:13:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 28 Feb 2018 02:13:14 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:59.0) Gecko/20100101 Thunderbird/59.0 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 Feb 28 03:13:10 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eqrEz-0006Vh-ES for geb-bug-gnu-emacs@m.gmane.org; Wed, 28 Feb 2018 03:13:09 +0100 Original-Received: from localhost ([::1]:41425 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eqrH1-00088w-N9 for geb-bug-gnu-emacs@m.gmane.org; Tue, 27 Feb 2018 21:15:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60888) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eqrGr-000888-OI for bug-gnu-emacs@gnu.org; Tue, 27 Feb 2018 21:15:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eqrGo-00066D-Hc for bug-gnu-emacs@gnu.org; Tue, 27 Feb 2018 21:15:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:56644) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eqrGo-00065t-D2 for bug-gnu-emacs@gnu.org; Tue, 27 Feb 2018 21:15:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eqrGo-00054d-7S for bug-gnu-emacs@gnu.org; Tue, 27 Feb 2018 21:15: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, 28 Feb 2018 02:15: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.151978404519390 (code B ref 20489); Wed, 28 Feb 2018 02:15:02 +0000 Original-Received: (at 20489) by debbugs.gnu.org; 28 Feb 2018 02:14:05 +0000 Original-Received: from localhost ([127.0.0.1]:36303 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eqrFt-00052f-7c for submit@debbugs.gnu.org; Tue, 27 Feb 2018 21:14:05 -0500 Original-Received: from mail-wr0-f172.google.com ([209.85.128.172]:38560) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eqrFq-000524-Um for 20489@debbugs.gnu.org; Tue, 27 Feb 2018 21:14:03 -0500 Original-Received: by mail-wr0-f172.google.com with SMTP id n7so762898wrn.5 for <20489@debbugs.gnu.org>; Tue, 27 Feb 2018 18:14:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Vmn+g41tYxJjfq8WYOPsIqK/Ssqx4BCPC8vGdSclok0=; b=d9AdsVLZRHh6ykQ0eowTVSkLxhvd5sRkPWHPA+++eY7p4qusKNCBMJOvBNKLSVhRx2 2xkLbLRSclnxD/ib+unDZh4qmxV7j5saNUG4iPp9MK2ACbn9Km8hiq+7RmVUJbi7LXD/ h8+Pu12Lahhh1JGLnxteDg5RcbGXrA68BOn9cTQq9WLVXRNjfTmI+2EA7tDWEbayXggS g0jzKgWsuzUrieGxkkHo6YI1dne6QlcqeTF/3Z3rL3g3BtSTJi/G7P0J6KD0IUJxvq4h veuHasNrPb8FgU3G7mLN2FuEINr+TzH7+PsEQ08eMzM8Ed1dUvc2jKLaailgRrmhsaSR qP4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Vmn+g41tYxJjfq8WYOPsIqK/Ssqx4BCPC8vGdSclok0=; b=dbT+wOLsolJqwO4a1a3GmtCPXnAK9hTUSz53vNGoM2zwBNupu96YcrvQIGJYM2oV0q 9mR92daolHWK3e/zsiGMYKD3fgDBGaMwepWarp9h5IXUvmESTVywoyAGwtuo9uy8v12W R65rT0X9s5mllgGe13urHBzW6PINBb6knH6XDK5gKwI6enp5ZgkGsgjhc1pq0GmcXn8B ddqtfXo9KVVh2nwP9FsrCz37VovkPVgPOCi0bmwvCKn3ic+sErDG0gxhAazzNi+xGPcV snlm9mqf5CJ+drVjTu7DMUqiH/mK8N7Du8Co5gNCFDaWsrXutXRe/rkMK+K+k5v1dP6J 0M8g== X-Gm-Message-State: APf1xPDpYr97YHXJgY9fqNvSCWDtaGKOaqOGGeAZv3tjYloEIwDDWBJg OOcMBLnBqsZHfpPL5UkdaXD41dPJ X-Google-Smtp-Source: AH8x2275M8XQEac8dwwfKHVSrAlMP7ik13lhiArDq56AB4vZZB3dfig6jhL/nlKWljPXSZgxY3r2lQ== X-Received: by 10.223.189.131 with SMTP id l3mr13983713wrh.140.1519784037004; Tue, 27 Feb 2018 18:13:57 -0800 (PST) Original-Received: from [192.168.1.3] ([185.105.174.23]) by smtp.googlemail.com with ESMTPSA id b81sm825472wmb.36.2018.02.27.18.13.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Feb 2018 18:13:55 -0800 (PST) In-Reply-To: <87efl6smxb.fsf@mail.linkov.net> Content-Language: en-US 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" Xref: news.gmane.org gmane.emacs.bugs:143728 Archived-At: On 2/27/18 11:16 PM, Juri Linkov wrote: >> On that subject: why did we make next-error-last-buffer always buffer-local? > > next-error-last-buffer is buffer-local to keep the reference to the > parent buffer used to navigate to the current buffer, so the next call of > next-buffer will use the same parent buffer to continue navigation from it. Thank you for the reminder. Looking at the previous discussion, I wasn't fond of this design back then, and still think it's largely unnecessary complexity (it introduces implicit state, and in the situations that it can be useful in, the user will have to remember which windows came from which navigation). Anyway, I've fixed the current problem (see below), so this is a matter of opinion. If you still consider this feature to be important, I think ideally we'd abstract it away behind a new -function variable as well. This way, someone would also be able to implement window-local navigation relationship instead of buffer-local (you've mentioned this option before). > This works well in most cases except the case of xref buffers. > Below is the explanation for code from next-error with added remarks: > > (defun next-error (&optional arg reset) > (let ((buffer (next-error-find-buffer))) > (when buffer > (with-current-buffer buffer > > Here the current buffer is *xref* > > (funcall next-error-function (prefix-numeric-value arg) reset) > > next-error-function should navigate from *xref* to another buffer > and change the current-buffer to the navigated buffer, e.g. ChangeLog.1. If that's something next-error-function must do, let's document it better. Right now it only says "Function to use to find the next error in the current buffer" (how does one "find" an error?) and describes input arguments, but not the return value (which is luckily unused) or which buffer must be current, or which window selected at the end. > This works fine in most cases, for example when next-error-function is > compilation-next-error-function, but fails when next-error-function is > xref--next-error-function that switches to ChangeLog.1, but doesn't set > the value current-buffer to ChangeLog.1. > > (setq next-error-last-buffer buffer) > > In normal cases this sets buffer-local next-error-last-buffer in the > navigated buffer, e.g. ChangeLog.1 that should be the current buffer. > But since xref--next-error-function doesn't set the right current buffer > to ChangeLog.1, this sets buffer-local next-error-last-buffer in the wrong > buffer, i.e. in *xref*. IOW, the value returned from (current-buffer) > is wrong here after xref--next-error-function call. I see. > So the question is: in xref--next-error-function can we use code similar > to what is used in compilation-next-error-function that works without problems? You probably mean compilation-goto-locus (it contains the navigation part), but even so, it's not easy to tell which part you mean (the function does more than one would expect). In short, adapting that code is kind of difficult, but hopefully I found and fixed the problem in xref directly in 11c58c4fc495ea4f7bff52ca077fd3e4382aa900.