GNU logs - #30674, boring messages

Message sent to juri@HIDDEN, bug-gnu-emacs@HIDDEN:

Subject: bug#30674: 27.0.50; flymake-mode should set next-error-function and (probably) next-error-last-buffer
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: juri@HIDDEN, bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 02 Mar 2018 01:16:02 +0000
Resent-Message-ID: <handler.30674.B.151995334327139 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 30674 <at> debbugs.gnu.org
Cc: juri@HIDDEN
From: Dmitry Gutov <dgutov@HIDDEN>
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
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

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)?

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Dmitry Gutov <dgutov@HIDDEN>
Subject: bug#30674: Acknowledgement (27.0.50; flymake-mode should set
 next-error-function and (probably) next-error-last-buffer)
Message-ID: <handler.30674.B.151995334327139.ack <at> debbugs.gnu.org>
References: <15327428-85fd-5b2e-1878-2b5b3b538375@HIDDEN>
X-Gnu-PR-Message: ack 30674
X-Gnu-PR-Package: emacs
Reply-To: 30674 <at> debbugs.gnu.org
Date: Fri, 02 Mar 2018 01:16:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

As you requested using X-Debbugs-CC, your message was also forwarded to
  juri@HIDDEN
(after having been given a bug report number, if it did not have one).

Your message has been sent to the package maintainer(s):
 bug-gnu-emacs@HIDDEN

If you wish to submit further information on this problem, please
send it to 30674 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
30674: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D30674
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#30674: 27.0.50; flymake-mode should set next-error-function and (probably) next-error-last-buffer
Resent-From: Juri Linkov <juri@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 06 Mar 2018 23:08:02 +0000
Resent-Message-ID: <handler.30674.B30674.152037766729124 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: 30674 <at> debbugs.gnu.org
From: Juri Linkov <juri@HIDDEN>
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
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

> 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.

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#30674: 27.0.50; flymake-mode should set next-error-function and (probably) next-error-last-buffer
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 13 Mar 2018 00:45:02 +0000
Resent-Message-ID: <handler.30674.B30674.15209018493332 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Juri Linkov <juri@HIDDEN>
Cc: 30674 <at> debbugs.gnu.org
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
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

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.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#30674: 27.0.50; flymake-mode should set next-error-function and (probably) next-error-last-buffer
Resent-From: Juri Linkov <juri@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 13 Mar 2018 23:25:01 +0000
Resent-Message-ID: <handler.30674.B30674.152098348217306 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 30674
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: 30674 <at> debbugs.gnu.org
Received: via spool by 30674-submit <at> debbugs.gnu.org id=B30674.152098348217306
          (code B ref 30674); Tue, 13 Mar 2018 23:25:01 +0000
Received: (at 30674) by debbugs.gnu.org; 13 Mar 2018 23:24:42 +0000
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>
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-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.

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

Received: (at control) by debbugs.gnu.org; 12 Dec 2022 08:50:26 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Dec 12 03:50:26 2022
Received: from localhost ([127.0.0.1]:51536 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1p4eW2-0004yf-43
	for submit <at> debbugs.gnu.org; Mon, 12 Dec 2022 03:50:26 -0500
Received: from mail-oa1-f52.google.com ([209.85.160.52]:44860)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <stefankangas@HIDDEN>) id 1p4eW1-0004yX-2v
 for control <at> debbugs.gnu.org; Mon, 12 Dec 2022 03:50:25 -0500
Received: by mail-oa1-f52.google.com with SMTP id
 586e51a60fabf-1447c7aa004so7558744fac.11
 for <control <at> debbugs.gnu.org>; Mon, 12 Dec 2022 00:50:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=to:subject:message-id:date:mime-version:from:from:to:cc:subject
 :date:message-id:reply-to;
 bh=NhXCQ7ZlnmOFRrnp+HRoAVcZXhV7xomyXxhWoZYICIo=;
 b=hOq+Wb45DWVbALtXIaTP8FnamlFlOOK3ZOC+dnEKxg1j3rnz4dHlUAFsoBD1y5Kr02
 BTIzj4hayOuJsDet91bfvh+XOeFp4x2ZDnFjX8bzPMGWpcAc3fyI7rzJ1Gz+6jPmMDgR
 FymjqWZEYyt9H8zZ1gbvD1llII85l5AcjvLwrF5qD8EhSsExpZsHgJeSQAwc9/LTfkzK
 uzL22lx3mzOrcUhOpwqT6HjhQAk/F0BMbWxfZdmt//So+BGS9AsuI4idrZxKJhgmOYsZ
 ceeC9Ps0zgRzdW4Uum73OYpLSjmz9q0oVjCvoCgbo5BAi4Sc9zl1R1bis5J0AaZ0C5px
 Nk4g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=to:subject:message-id:date:mime-version:from:x-gm-message-state
 :from:to:cc:subject:date:message-id:reply-to;
 bh=NhXCQ7ZlnmOFRrnp+HRoAVcZXhV7xomyXxhWoZYICIo=;
 b=6WZeliY186D1RuNc+GkZdxiJkmgopqrEF135wFx04tr8xaLuVi8XJMj7e52JNa5iiD
 bboR6uA1B9Cy7we15acKz3KtHc9wwVtgoX4OHHN5HOQqF/EgTzPHnT4cBHCxIuX2t9mQ
 b7r7fJ1KkOXxfCCiu18x7YobpP4aWsS+Ujvcp+cahpvxKXB/MlJ46iQqP/8F5vEAwZ3w
 Xf2xrPBJdhK870xWgYg9UPApV7vDdJ+aLE3WdSW0E31Fa10TAliXjgllf7AHWo3GisCg
 01ZAL9E7BUYvvV9p/6K5qAAfdDvY+/jkM06DCLzbOKmdr7HTdgqTgqhd8gBts7lo9n0y
 ZJ4A==
X-Gm-Message-State: ANoB5pkwKFJg47HXJWy7oq5ww5UW5IkZVlSz211ccrYMUE7vcNJFdk0r
 bpTOH1sIaWTEk0TSnuGJzhsPkpGEo/cUBwEzBtVNWGND
X-Google-Smtp-Source: AA0mqf6mc69gzyda3C1sUqiV1P2RM+mV2KkmiHZMuJ3yYTmLypgJwjNSE6AkPgYr+2JbNNQp+clzmBHLYSiRoj0Ceeo=
X-Received: by 2002:a05:6870:668a:b0:145:3a7:99c with SMTP id
 ge10-20020a056870668a00b0014503a7099cmr1067899oab.92.1670835019478; Mon, 12
 Dec 2022 00:50:19 -0800 (PST)
Received: from 753933720722 named unknown by gmailapi.google.com with
 HTTPREST; Mon, 12 Dec 2022 00:50:18 -0800
From: Stefan Kangas <stefankangas@HIDDEN>
X-Hashcash: 1:20:221212:control <at> debbugs.gnu.org::nZX8U16urAH1BVZo:1L0D
MIME-Version: 1.0
Date: Mon, 12 Dec 2022 00:50:18 -0800
Message-ID: <CADwFkm=0AoT=isGW4182HAMQg87A9cJd-oCxUL_petQaYwjpFA@HIDDEN>
Subject: control message for bug #30674
To: control <at> debbugs.gnu.org
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: control
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: -1.0 (-)

severity 30674 wishlist
quit

Last modified: Mon, 12 Dec 2022 09:00:02 UTC

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