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

Previous Next

Package: emacs;

Reported by: Dmitry Gutov <dgutov <at> yandex.ru>

Date: Fri, 2 Mar 2018 01:16:02 UTC

Severity: wishlist

Found in version 27.0.50

Full log


Message #8 received at 30674 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 30674 <at> debbugs.gnu.org
Subject: Re: bug#30674: 27.0.50;
 flymake-mode should set next-error-function and (probably)
 next-error-last-buffer
Date: Wed, 07 Mar 2018 00:33:59 +0200
> 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)?

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




This bug report was last modified 2 years and 281 days ago.

Previous Next


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