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: Fri, 2 Mar 2018 03:19:01 +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> <87zi3s7r16.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 1519953494 25292 195.159.176.226 (2 Mar 2018 01:18:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 2 Mar 2018 01:18: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 Fri Mar 02 02:18:09 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 1erZKr-0005ov-8N for geb-bug-gnu-emacs@m.gmane.org; Fri, 02 Mar 2018 02:18:09 +0100 Original-Received: from localhost ([::1]:59995 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1erZMs-0005RQ-68 for geb-bug-gnu-emacs@m.gmane.org; Thu, 01 Mar 2018 20:20:14 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51338) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1erZMk-0005RD-LT for bug-gnu-emacs@gnu.org; Thu, 01 Mar 2018 20:20:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1erZMg-0006MV-QZ for bug-gnu-emacs@gnu.org; Thu, 01 Mar 2018 20:20:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:60230) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1erZMg-0006MG-MH for bug-gnu-emacs@gnu.org; Thu, 01 Mar 2018 20:20:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1erZMg-0007AG-GD for bug-gnu-emacs@gnu.org; Thu, 01 Mar 2018 20:20: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: Fri, 02 Mar 2018 01:20: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.151995355227478 (code B ref 20489); Fri, 02 Mar 2018 01:20:02 +0000 Original-Received: (at 20489) by debbugs.gnu.org; 2 Mar 2018 01:19:12 +0000 Original-Received: from localhost ([127.0.0.1]:39894 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1erZLr-000798-RA for submit@debbugs.gnu.org; Thu, 01 Mar 2018 20:19:12 -0500 Original-Received: from mail-wr0-f177.google.com ([209.85.128.177]:36000) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1erZLp-00078t-GW for 20489@debbugs.gnu.org; Thu, 01 Mar 2018 20:19:10 -0500 Original-Received: by mail-wr0-f177.google.com with SMTP id v111so8493068wrb.3 for <20489@debbugs.gnu.org>; Thu, 01 Mar 2018 17:19:09 -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=5NWB793XoC5pj57+NjFEVfO3ok8+p8VSry2xwGNJ6fg=; b=hCNRi1WP/5RwMNN9fJGwj0l9Ybn+BgXswRl79wIbE8223GwEejz0LIOWdygm2vmyzX 3RI/Lr+v/J1fOdxxAq2Vu+YxoNB5ud+ZzGb1CyiIoYEGjoMSCRAY6dT9Jn5Bgdfet2DA uTby/OYyGpBRK+VL6S8gfCbQIlZPiUr7j7IUSSbp0pesdUismT1lYouOs0v7kFv5nqmn GnXR/RWH71eiJ+xgjGEw3msUjipicciX+5GjbzQ5Xj4ds+dIFoADyyyprMQVDqxTqEiO 0VyXoc9TQRVKn0oZFfhe0t3hvt0bXxnb+q7lMVKOLz8m98ij+GlSGlFoAfcmKiM+YGzS rrcw== 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=5NWB793XoC5pj57+NjFEVfO3ok8+p8VSry2xwGNJ6fg=; b=dJ/fvhtMB5QhLtWIaoDrYOCZdcsruMjMF8SiWC652iGX3uFLrjOlWFVx1My42EdxJ8 +Y0vTov+opMtLXEdJM36Wcgxopg7T+hMagYrXMI0z2niQt6TTNU72oZT8F5AYC85KreP ncOPZGztyM61jLUNVs3pprj/bPjSR5G3sYpXUnfUjV3AtEOAp0cDE2DTC5eZj7aB43Qp CqlqZVEvdyC0luyhyW2Fj/15l3sqXcrCtVa49tfLFS5PYk0vV/IotatZ7OLMuvqJO63l I0w61GIAE7CdhN/w7+BJaA2b1vl5jpWIE+VF7jkAnut9nL+DZQc/CdXc371N6+wzEHMn 8ddw== X-Gm-Message-State: APf1xPDthexyXMZ+YGaO/1MCaN/L5klP7YMgavhJr4Vpjs/PP8NswnmF 6LN3Nl4i4kMZv6JBPVUgrDLMZ8Ic X-Google-Smtp-Source: AG47ELug/PFY82u6XId3EUwI/ImFJLDn2/OyRaEGPSmwZa0U71NdyLJnAuC1wRXiwqZtjnOozZN+CQ== X-Received: by 10.223.157.205 with SMTP id q13mr3383485wre.266.1519953543465; Thu, 01 Mar 2018 17:19:03 -0800 (PST) Original-Received: from [192.168.1.3] ([185.105.174.23]) by smtp.googlemail.com with ESMTPSA id q9sm5675717wrf.11.2018.03.01.17.19.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Mar 2018 17:19:02 -0800 (PST) In-Reply-To: <87zi3s7r16.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:143814 Archived-At: On 2/28/18 11:17 PM, Juri Linkov wrote: >> 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. > > Please clarify what do you have in mind. In what place in code such > function could be called? Any place that contains (setq next-error-last-buffer buffer) (setq-default next-error-last-buffer buffer) now, would instead call (funcall next-error-save-last-buffer-function target-buf target-win) >> This way, someone would also be able to implement window-local navigation >> relationship instead of buffer-local (you've mentioned this option before). > > Window-local navigation could be implemented by something like below. > But maybe window-local specific code in next-error and next-error-internal > could be abstracted away in a function that you proposed above? Yes. next-error-save-last-buffer-function and next-error-find-buffer-function would have to be in sync (we'd have to somehow make sure the user will have to try hard to set them to incompatible values, at least if they do that via the Customize interface). Further, I think next-error-find-buffer-function will also have to encompass the item 2 in next-error-find-buffer, so that the alternative could supply the window-local value instead. Anyway, I'd really like to put a pin in both buffer-local and window-local values for now, because they both complicate the picture. Instead, could we address bug#30674 first? Personally, moving between errors and warnings in the current file using next/previous-error feels a lot more useful.