[Top][All Lists]

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

Re: Flymake refactored

From: Ted Zlatanov
Subject: Re: Flymake refactored
Date: Fri, 29 Sep 2017 13:56:21 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)

On Fri, 29 Sep 2017 19:35:38 +0200 Dmitry Gutov <address@hidden> wrote: 

DG> On 9/29/17 6:26 PM, Ted Zlatanov wrote:
>> I was specifically talking about how Flymake should integrate with
>> next-error. Sorry I didn't make that clearer.

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

I'd go for "unsurprising" :)

>> I'm not sure if you want to follow up on that bug or here in a new
>> thread, but if you want to make a branch with the changes you think
>> would improve the next-error DWIM experience, I'll be glad to take a
>> look and test it with my workflows. That would probably be the most
>> effective way.

DG> Hopefully, someday. Right now, I see how it shouldn't work, but I don't 
DG> see how it should.

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.


reply via email to

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