GNU bug report logs - #30674
27.0.50; flymake-mode should set next-error-function and (probably) next-error-last-buffer

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: emacs; Severity: minor; Reported by: Dmitry Gutov <dgutov@HIDDEN>; dated Fri, 2 Mar 2018 01:16:02 UTC; Maintainer for emacs is bug-gnu-emacs@HIDDEN.

Message received at 30674 <at> debbugs.gnu.org:


Received: (at 30674) by debbugs.gnu.org; 13 Mar 2018 23:24:42 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Mar 13 19:24:42 2018
Received: from localhost ([127.0.0.1]:60137 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1evtHd-0004V2-UG
	for submit <at> debbugs.gnu.org; Tue, 13 Mar 2018 19:24:42 -0400
Received: from sub3.mail.dreamhost.com ([69.163.253.7]:43766
 helo=homiemail-a18.g.dreamhost.com)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <juri@HIDDEN>) id 1evtHc-0004Us-2Q
 for 30674 <at> debbugs.gnu.org; Tue, 13 Mar 2018 19:24:40 -0400
Received: from homiemail-a18.g.dreamhost.com (localhost [127.0.0.1])
 by homiemail-a18.g.dreamhost.com (Postfix) with ESMTP id 060E1258067;
 Tue, 13 Mar 2018 16:24:39 -0700 (PDT)
Received: from localhost.linkov.net (m91-129-107-5.cust.tele2.ee
 [91.129.107.5])
 (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
 (No client certificate requested)
 (Authenticated sender: jurta@HIDDEN)
 by homiemail-a18.g.dreamhost.com (Postfix) with ESMTPSA id 2F59B258066;
 Tue, 13 Mar 2018 16:24:37 -0700 (PDT)
From: Juri Linkov <juri@HIDDEN>
To: Dmitry Gutov <dgutov@HIDDEN>
Subject: Re: bug#30674: 27.0.50;
 flymake-mode should set next-error-function and (probably)
 next-error-last-buffer
Organization: LINKOV.NET
References: <15327428-85fd-5b2e-1878-2b5b3b538375@HIDDEN>
 <87a7vkrelc.fsf@HIDDEN>
 <618839ea-9fcb-70c2-4152-b0b5d2327083@HIDDEN>
Date: Wed, 14 Mar 2018 00:23:45 +0200
In-Reply-To: <618839ea-9fcb-70c2-4152-b0b5d2327083@HIDDEN> (Dmitry Gutov's
 message of "Tue, 13 Mar 2018 02:43:56 +0200")
Message-ID: <8737138sqm.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 30674
Cc: 30674 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)

>> I guess to cancel such navigation is possible in at least three ways:
>> doing window-quit on the *Occur* buffer,
>
> For this, next-error-find-buffer-function should be set to
> #'next-error-buffer-on-selected-frame.

Yes, and in this case you can see the clarity and predictability of
this option: when the *Occur* buffer is visible on the selected frame,
next-error will navigate the occur results as the user will expect.
Hiding the window with the *Occur* buffer will switch navigation
to Flymake warnings in the current buffer.  This is what can be called
WYSIWYG.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#30674; Package emacs. Full text available.

Message received at 30674 <at> debbugs.gnu.org:


Received: (at 30674) by debbugs.gnu.org; 13 Mar 2018 00:44:09 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Mar 12 20:44:09 2018
Received: from localhost ([127.0.0.1]:57845 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1evY2y-0000rf-PP
	for submit <at> debbugs.gnu.org; Mon, 12 Mar 2018 20:44:09 -0400
Received: from mail-wr0-f175.google.com ([209.85.128.175]:43893)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1evY2x-0000rI-D2
 for 30674 <at> debbugs.gnu.org; Mon, 12 Mar 2018 20:44:07 -0400
Received: by mail-wr0-f175.google.com with SMTP id o1so6057203wro.10
 for <30674 <at> debbugs.gnu.org>; Mon, 12 Mar 2018 17:44:07 -0700 (PDT)
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=idEAR41g1QLsDQStb3/kHHEeRrdYo9fbUxzUqENkrXM=;
 b=Pd0d8fw8Hnm/yz6WT4B7W/OtFsZDuK4qLNN+zPZ3m+YjHKYKsiVLS1nFxg7qK0zYXI
 kDAxIY+/p5jTFbWhJtyJ+6ykPbXPBoXZvSZX7dtjKMh0CqjO6+ufpOS3+jHeAZInG5/P
 C8pmyd9EKFp2Hd7RdAOjN29qgw+HWAaTsWJdDDyiVbvNyS0HEp0Cm63GrZmU32/J5in0
 PSHtRHkJnZr2hdfLc79bhMGcXjFMGpUubxmMsL+NENlTky8Ug2OkusqL/PBmjFoFBqsK
 ZnjgwIXaX8HW47ySacASNlbdXRdsqkjln5urse5ECNipEhM4NrHLTHc7dG7d7+hKhGrd
 oqeQ==
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=idEAR41g1QLsDQStb3/kHHEeRrdYo9fbUxzUqENkrXM=;
 b=BNwmHVj2jGpGapFoIwNqXWzGQjJH8H0uC1rHZSUNil0Lsk1k546tADqAEChtDMLZGm
 Qsw9c82zGmrIm5jt9ax6MBEkyB//z3FXCo4QhFGn4EqtRQNhXHAQAjdrvMmU612JXReF
 /NvpvnJbIxqP3iS0qUE/5iWnwxXGgHAjRN/hq/9voJiRt6GWJV25UYDJJ+YxNyn9IRRU
 4bRYyKYk9fRltWv/HtkBeg7D6D88NEq6Py+8gKgfxl+k8wU1h+WhJeoqXuUuf+jcExYo
 loybDeGxsRSoYWw/yMW7C97efyQuiS9bpbrKGN0YLqsqQ/GqC1+uOHIwF3IqLbYWAV6C
 8D2w==
X-Gm-Message-State: AElRT7H9qZZZVKek8WlFhgfBpsAVlkI1/Ugpiu30+DjgMN9Tb3KDV1kE
 MRPK3hi2IchRAqowaPGUhIZ0A5cY
X-Google-Smtp-Source: AG47ELvxQrO3RnlmWNhe1Kvx7zscHh1BOnn9sXyZCBw92orZDfyzSPUgvE7Ze1wQX5BCeqt8dMpOIQ==
X-Received: by 10.223.134.170 with SMTP id 39mr7346894wrx.221.1520901840883;
 Mon, 12 Mar 2018 17:44:00 -0700 (PDT)
Received: from [192.168.1.3] ([185.105.174.23])
 by smtp.googlemail.com with ESMTPSA id y1sm7715623wrh.80.2018.03.12.17.43.57
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Mon, 12 Mar 2018 17:43:59 -0700 (PDT)
Subject: Re: bug#30674: 27.0.50; flymake-mode should set next-error-function
 and (probably) next-error-last-buffer
To: Juri Linkov <juri@HIDDEN>
References: <15327428-85fd-5b2e-1878-2b5b3b538375@HIDDEN>
 <87a7vkrelc.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <618839ea-9fcb-70c2-4152-b0b5d2327083@HIDDEN>
Date: Tue, 13 Mar 2018 02:43:56 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:59.0) Gecko/20100101
 Thunderbird/59.0
MIME-Version: 1.0
In-Reply-To: <87a7vkrelc.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.5 (/)
X-Debbugs-Envelope-To: 30674
Cc: 30674 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.5 (/)

On 3/7/18 12:33 AM, Juri Linkov wrote:

> I think it would be a natural fit into the next-error framework.  How to
> solve conflicts with other sources of next-error is an open question.
> For example, after running ‘occur’ on the flymake-mode enabled buffer
> next-error should continue navigating ‘occur’ hits.

Right. That creates tradeoffs, which in turn push against the 
flexibility of next-error-find-buffer-function: it's going to more than 
aesthetic choice now.

So I wonder which particular scheme, or schemes, people actually prefer. 
Or which they'd understand more quickly, just by experimenting (that 
might be the best default).

> I guess to cancel
> such navigation is possible in at least three ways: doing window-quit
> on the *Occur* buffer,

For this, next-error-find-buffer-function should be set to 
#'next-error-buffer-on-selected-frame. Or will we have a separate 
predicate function for whether to use the "local" next-error-function?

> or using next-error-select-buffer selecting
> the current buffer (instead of the *Occur* buffer),

That might be too tedious, having to do that for every 
buffer-with-local-errors you switch to and try to edit (and fix 
errors/warnings in).

However, if we special-case the nil value of next-error-last-buffer, it 
might not be so tedious: you switch away from the last Occur/Grep/etc 
buffer with one invocation, and go on editing multiple files.

This is where buffer-local (or window-local) values of 
next-error-last-buffer might bring undesirable behavior: if one of those 
multiple files was another navigation target from an Occur/Grep/etc 
navigation, or if we switch to a window that was the target (in the 
window-local case), the user will need another next-error-select-buffer 
invocation, and they won't know that until their next-error call brings 
them somewhere unexpected (and only winner-mode will help undo that).

There can be other approaches, such as when there's no visible 
global-next-error-capable buffers, and the current one is 
next-error-capable, use it, as long as there are local errors in the 
given direction, and then switch over to the global navigation.

> or re-running flymake
> on the buffer.

That might be annoying: it runs every time a buffer is saved (and even 
right after it's visited if flymake-start-on-flymake-mode is non-nil).

But hey, it can also be a fine approach, as long as 
flymake-start-on-flymake-mode is nil. Recalling that the first idea is 
to only use a global navigation as long as its buffer is visible, let's 
imagine that it's also so in this case. Grep tries very hard to stay 
visible.

So, we run Grep, jump from it to a source file, start editing. Flymake 
runs, shows some warnings. If the user fixes them all, maybe switch back 
to the global navigation automatically; if not, select Grep's window and 
manually navigate to the next error in the list using one of its 
"buttons" (which also sets next-error-last-buffer). And if the 
navigation buffer is not visible, the user can call 
next-error-select-buffer anyway.

This can work well, as long as the user understands what's going on.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#30674; Package emacs. Full text available.

Message received at 30674 <at> debbugs.gnu.org:


Received: (at 30674) by debbugs.gnu.org; 6 Mar 2018 23:07:47 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Mar 06 18:07:47 2018
Received: from localhost ([127.0.0.1]:48197 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1etLgR-0007Zg-KX
	for submit <at> debbugs.gnu.org; Tue, 06 Mar 2018 18:07:47 -0500
Received: from sub3.mail.dreamhost.com ([69.163.253.7]:48854
 helo=homiemail-a100.g.dreamhost.com)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <juri@HIDDEN>) id 1etLgQ-0007ZZ-JC
 for 30674 <at> debbugs.gnu.org; Tue, 06 Mar 2018 18:07:46 -0500
Received: from homiemail-a100.g.dreamhost.com (localhost [127.0.0.1])
 by homiemail-a100.g.dreamhost.com (Postfix) with ESMTP id 2A9E031A078;
 Tue,  6 Mar 2018 15:07:46 -0800 (PST)
Received: from localhost.linkov.net (m91-129-110-147.cust.tele2.ee
 [91.129.110.147])
 (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
 (No client certificate requested)
 (Authenticated sender: jurta@HIDDEN)
 by homiemail-a100.g.dreamhost.com (Postfix) with ESMTPSA id 4A91B31A075;
 Tue,  6 Mar 2018 15:07:45 -0800 (PST)
From: Juri Linkov <juri@HIDDEN>
To: Dmitry Gutov <dgutov@HIDDEN>
Subject: Re: bug#30674: 27.0.50;
 flymake-mode should set next-error-function and (probably)
 next-error-last-buffer
Organization: LINKOV.NET
References: <15327428-85fd-5b2e-1878-2b5b3b538375@HIDDEN>
Date: Wed, 07 Mar 2018 00:33:59 +0200
In-Reply-To: <15327428-85fd-5b2e-1878-2b5b3b538375@HIDDEN> (Dmitry Gutov's
 message of "Fri, 2 Mar 2018 03:15:26 +0200")
Message-ID: <87a7vkrelc.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 30674
Cc: 30674 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)

> Considering the names and docstrings of next-error and previous-error, =
I
> think it's quite reasonable to expect to be able to navigate the Flymak=
e
> diagnostics with them.
>
> Jo=C3=A3o, was there a particular reason you decided against it? Can we
> improve next-error somehow, for this to become more appealing?
>
> Juri, any thoughts? The foremost apparent difficulty is that virtually
> any file-editing buffer can become a next-error capable buffer. Would
> opening a new file interactively (with flymake-mode being turned on)
> automatically change next-error-last-buffer? Would it change after
> save-buffer (after which diagnostics are normally refreshed)?

I think it would be a natural fit into the next-error framework.  How to
solve conflicts with other sources of next-error is an open question.
For example, after running =E2=80=98occur=E2=80=99 on the flymake-mode en=
abled buffer
next-error should continue navigating =E2=80=98occur=E2=80=99 hits.  I gu=
ess to cancel
such navigation is possible in at least three ways: doing window-quit
on the *Occur* buffer, or using next-error-select-buffer selecting
the current buffer (instead of the *Occur* buffer), or re-running flymake
on the buffer.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#30674; Package emacs. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 2 Mar 2018 01:15:43 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Mar 01 20:15:43 2018
Received: from localhost ([127.0.0.1]:39888 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1erZIV-00073f-Aa
	for submit <at> debbugs.gnu.org; Thu, 01 Mar 2018 20:15:43 -0500
Received: from eggs.gnu.org ([208.118.235.92]:58056)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1erZIT-00073T-FO
 for submit <at> debbugs.gnu.org; Thu, 01 Mar 2018 20:15:42 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <raaahh@HIDDEN>) id 1erZIN-0003RF-Hl
 for submit <at> debbugs.gnu.org; Thu, 01 Mar 2018 20:15:36 -0500
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: *
X-Spam-Status: No, score=1.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM,
 FREEMAIL_REPLY,T_DKIM_INVALID autolearn=disabled version=3.3.2
Received: from lists.gnu.org ([2001:4830:134:3::11]:57777)
 by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32)
 (Exim 4.71) (envelope-from <raaahh@HIDDEN>) id 1erZIN-0003R7-Dq
 for submit <at> debbugs.gnu.org; Thu, 01 Mar 2018 20:15:35 -0500
Received: from eggs.gnu.org ([2001:4830:134:3::10]:49010)
 by lists.gnu.org with esmtp (Exim 4.71)
 (envelope-from <raaahh@HIDDEN>) id 1erZIM-0004oV-9h
 for bug-gnu-emacs@HIDDEN; Thu, 01 Mar 2018 20:15:35 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <raaahh@HIDDEN>) id 1erZIJ-0003NW-3p
 for bug-gnu-emacs@HIDDEN; Thu, 01 Mar 2018 20:15:34 -0500
Received: from mail-wm0-x22d.google.com ([2a00:1450:400c:c09::22d]:52890)
 by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16)
 (Exim 4.71) (envelope-from <raaahh@HIDDEN>) id 1erZII-0003Md-St
 for bug-gnu-emacs@HIDDEN; Thu, 01 Mar 2018 20:15:31 -0500
Received: by mail-wm0-x22d.google.com with SMTP id t3so274921wmc.2
 for <bug-gnu-emacs@HIDDEN>; Thu, 01 Mar 2018 17:15:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=sender:to:from:subject:message-id:date:user-agent:mime-version
 :content-language:content-transfer-encoding;
 bh=GL5+pyts6qPGXWWos7RAv14jza4eb2fltChuXd/DZZ4=;
 b=gCHpGufRAGoN7ikQs28b6ZowRVfYCUKNn/kWcPPD3rGBW44mqVkwKq5LmOJOqUO6Tv
 SPMcA99O9AX6nkEtFzWPBL9APL05mZHuNg2E976rbwTuJzkaaQFFyNeb7NJ/yYY4s4Sl
 tWqDwIn2rppJ/Q9tHsm7baOOPfSvctd2hoqSF2kk77DI0x/VOBcIQrMlqbEMkngY0ZuM
 VEAYvmakreJ7RAM7o7oIbro+hSpfaEu2u4fLBt24Qpu1xHmjexk4Mo4pECua13ZcgeQb
 LUCxbCQgYRl2pwaecSS06MxshFlIMXUw2UdXogYDDaUT1ZSfw/Cl4C4gQzFTGywHuzxq
 3MpA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:sender:to:from:subject:message-id:date
 :user-agent:mime-version:content-language:content-transfer-encoding;
 bh=GL5+pyts6qPGXWWos7RAv14jza4eb2fltChuXd/DZZ4=;
 b=mQGrnfP97mlauFEbpsJZmfrJ+m/yt3gvnBjWaRZsNm2TQ4Rjq/QZoSIVdyGWrjVcX6
 gh/gFFzWPF9l2ie+2Zn3Hv1Hg1ir3+46vkSR/kRMnq2kuC239K5LKQXUuwaiGs1dJWdb
 vblycWnaxlnq5KG51XyytV83792O0WQHw4hma44UNMsI5XFlleHCL1YsqMlrutL0s49L
 X6HiGYGqreOvgU1KR1XHgBU4UXDBv/0GepOMRb2bliaJYKtuv55TsH4IpjuVZG4fpGZP
 YG+v7/GnBXyTOSV3q19eOc+5MsyBEEddIz1WV3x6o2rwSKz+4hNGQDDbrvekDnZWECqT
 CWZw==
X-Gm-Message-State: AElRT7F8522SVTb1RTa2KBkDkab6vWZXNw+CMEModzymkRGgWUCp3pNx
 eC2SP+X2cCQGZw2yGWyvjZQs6hLP
X-Google-Smtp-Source: AG47ELutVUtPqH0RBLx1HCAh+ORS3bRvZmLdDzZ13LJXhiDE2uBy/b6YWEH4Up32EQ1r1bkjj8yisg==
X-Received: by 10.28.27.194 with SMTP id b185mr155715wmb.102.1519953328966;
 Thu, 01 Mar 2018 17:15:28 -0800 (PST)
Received: from [192.168.1.3] ([185.105.174.23])
 by smtp.googlemail.com with ESMTPSA id d5sm273715wma.18.2018.03.01.17.15.27
 for <bug-gnu-emacs@HIDDEN>
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Thu, 01 Mar 2018 17:15:27 -0800 (PST)
To: bug-gnu-emacs@HIDDEN
From: Dmitry Gutov <dgutov@HIDDEN>
Subject: 27.0.50; flymake-mode should set next-error-function and (probably)
 next-error-last-buffer
Message-ID: <15327428-85fd-5b2e-1878-2b5b3b538375@HIDDEN>
Date: Fri, 2 Mar 2018 03:15:26 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:59.0) Gecko/20100101
 Thunderbird/59.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-detected-operating-system: by eggs.gnu.org: Genre and OS details not
 recognized.
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x
X-Received-From: 2001:4830:134:3::11
X-Spam-Score: -2.5 (--)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.5 (---)

X-Debbugs-CC: joaotavora@HIDDEN
X-Debbugs-CC: juri@HIDDEN

Considering the names and docstrings of next-error and previous-error, I
think it's quite reasonable to expect to be able to navigate the Flymake
diagnostics with them.

João, was there a particular reason you decided against it? Can we
improve next-error somehow, for this to become more appealing?

Juri, any thoughts? The foremost apparent difficulty is that virtually
any file-editing buffer can become a next-error capable buffer. Would
opening a new file interactively (with flymake-mode being turned on)
automatically change next-error-last-buffer? Would it change after
save-buffer (after which diagnostics are normally refreshed)?




Acknowledgement sent to Dmitry Gutov <dgutov@HIDDEN>:
New bug report received and forwarded. Copy sent to juri@HIDDEN, bug-gnu-emacs@HIDDEN. Full text available.
Report forwarded to juri@HIDDEN, bug-gnu-emacs@HIDDEN:
bug#30674; Package emacs. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Last modified: Mon, 25 Nov 2019 12:00:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.