[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Flymake refactored

From: Dmitry Gutov
Subject: Re: Flymake refactored
Date: Sat, 30 Sep 2017 17:07:07 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101 Thunderbird/56.0

On 9/29/17 7:56 PM, Ted Zlatanov wrote:

DG> It's still not clear to me, then. Should Flymake integration be "messy"?

I'd go for "unsurprising" :)

Then the concerns about M-x next-error should still apply.

It might be productive to gather use cases and workflows. Those were
missing in the bug discussion, and will probably make it clearer.

For instance, my typical Flycheck interaction while writing CFEngine
code is to keep 1-2 cfengine-mode buffers open (next-error just
navigates between syntax errors in the visible buffer) and to sometimes
pop up an Occur buffer (in which case I want to navigate ocurrences for
as long as the Occur buffer is visible). I generally don't compile,
grep, or git grep in that workflow.

I wouldn't say I have a specific workflow, but I do have a habit of killing or quitting windows or otherwise hiding buffers which I'm not looking at directly.

But there are some scenarios mentioned in the bug discussion, e.g. in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20489#74, earlier in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20489#44, and earlier again in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20489#32.

Please send any further replies to this to the bug address.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]