From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.bugs Subject: bug#28864: 25.3.50; next-error-no-select does select Date: Mon, 06 Nov 2017 23:41:38 +0200 Organization: LINKOV.NET Message-ID: <87k1z36q5p.fsf@mail.linkov.net> References: <87bml72qck.fsf@gmail.com> <6f3b7c2c-31af-8eb2-8f13-a9ba17d3d8e6@yandex.ru> <87mv4m5lok.fsf@gmail.com> <87d15h5f97.fsf@gmail.com> <874lqreyj5.fsf@localhost> <7f67cb1c-062f-44fa-ba8e-9ac0cab220a3@yandex.ru> <87po9del14.fsf@localhost> <5c524170-7ba7-8279-41b5-b4286c2980f0@yandex.ru> <87tvyomh37.fsf@localhost> <7821c28e-3bf5-0bab-46ab-23f3a02566a8@yandex.ru> <87po97vuoh.fsf@localhost> <87778f88-a6e6-06d5-f5ad-8a46d73144cc@yandex.ru> <87efplk4vu.fsf@localhost> <87tvyg72z1.fsf@localhost> <87o9onc775.fsf@localhost> <0cee613e-6189-2eef-2407-b84c46dd3175@yandex.ru> <87h8uc1guj.fsf@localhost> <69923498-b04d-6d23-ac99-1edb2ac49afe@yandex.ru> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1510004599 29124 195.159.176.226 (6 Nov 2017 21:43:19 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 6 Nov 2017 21:43:19 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) Cc: Noam Postavsky , 28864-done@debbugs.gnu.org, Tino Calancha To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Nov 06 22:43:15 2017 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 1eBpAp-0007QJ-HP for geb-bug-gnu-emacs@m.gmane.org; Mon, 06 Nov 2017 22:43:15 +0100 Original-Received: from localhost ([::1]:50372 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eBpAw-0005PR-VS for geb-bug-gnu-emacs@m.gmane.org; Mon, 06 Nov 2017 16:43:22 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47940) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eBpAh-0005L7-96 for bug-gnu-emacs@gnu.org; Mon, 06 Nov 2017 16:43:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eBpAc-0004Nn-DE for bug-gnu-emacs@gnu.org; Mon, 06 Nov 2017 16:43:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:46023) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eBpAc-0004NZ-9u for bug-gnu-emacs@gnu.org; Mon, 06 Nov 2017 16:43:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eBpAc-0008L2-3d for bug-gnu-emacs@gnu.org; Mon, 06 Nov 2017 16:43:02 -0500 Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-To: bug-gnu-emacs@gnu.org Resent-Date: Mon, 06 Nov 2017 21:43:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: cc-closed 28864 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Mail-Followup-To: 28864@debbugs.gnu.org, juri@linkov.net, tino.calancha@gmail.com Original-Received: via spool by 28864-done@debbugs.gnu.org id=D28864.151000455632014 (code D ref 28864); Mon, 06 Nov 2017 21:43:01 +0000 Original-Received: (at 28864-done) by debbugs.gnu.org; 6 Nov 2017 21:42:36 +0000 Original-Received: from localhost ([127.0.0.1]:54702 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eBpAB-0008KI-Nb for submit@debbugs.gnu.org; Mon, 06 Nov 2017 16:42:35 -0500 Original-Received: from sub3.mail.dreamhost.com ([69.163.253.7]:36368 helo=homiemail-a39.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eBpAA-0008KB-6X for 28864-done@debbugs.gnu.org; Mon, 06 Nov 2017 16:42:34 -0500 Original-Received: from homiemail-a39.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a39.g.dreamhost.com (Postfix) with ESMTP id 4219015006D; Mon, 6 Nov 2017 13:42:30 -0800 (PST) Original-Received: from localhost.linkov.net (m83-179-179-228.cust.tele2.ee [83.179.179.228]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by homiemail-a39.g.dreamhost.com (Postfix) with ESMTPSA id E253C150069; Mon, 6 Nov 2017 13:42:28 -0800 (PST) In-Reply-To: <69923498-b04d-6d23-ac99-1edb2ac49afe@yandex.ru> (Dmitry Gutov's message of "Sun, 5 Nov 2017 15:37:15 +0200") 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:139527 Archived-At: >>> I'm not sure either can be congruent to all next-error-function >>> applications. Some next-error source buffers contain their own errors (so >>> buffer-local is natural), and others point to errors in other buffers >>> (supposing they can learn to open those in the same window, window-local >>> might be fitting). But both kinds are there, and all users deal with both. >> >> They can learn to open those in the same window by the patch below. > > If 'next-error', from any source, opens its target in the same window, does > that make window-local storage essentially the same as frame-local > in practice? Not necessarily. It's possible to have several pairs of next-error source and target windows, each navigating in its own corresponding window, e.g. *grep* visiting files in one window, and *compilation* in another. >>>> 3. frame-local - old implicit default now separated into its own function >>> >>> That doesn't sound like a sufficient description: the old default also >>> includes visibility-based logic. So it's not just one value per frame. >> >> Do you think we should use the real frame-parameter? > > I almost never use more than one frame, so I wouldn't know. But if you use > a frame-parameter only, won't that break backward compatibility? I don't use more than one frame too, so I can't say how useful it would be. So let's leave only the previous code as an option. >>> is the new next-error-find-buffer stuff necessary to >>> fix the current bug? Or is suppressing the change to next-error-last-buffer >>> during next-error-function calls enough for that? >> >> The key point is (setq next-error-last-buffer) after >> (funcall next-error-function), not before. > > Thanks. So maybe we can split your patch into two parts: one that fixes the > complaint in just this bug report, and the rest that aims to improve the > general behavior. > > We could push the first one right away, and continue discussing the second > one. I'd like to see some new voices too, not just us two. Good point. Closed to be continued in bug#20489.