Re: Flymake refactored

[joaotavora@gmail.com (João Távora)]

Mark Oteiza <mvoteiza@udel.edu> writes:

> On 07/10/17 at 05:07pm, João Távora wrote:
>> Mark Oteiza <mvoteiza@udel.edu> writes:
>> 
>> > Sure, I've been reading flycheck and syntastic (analogous package for
>> > vim) for reference.
>> >
>> > There are some things aside from checkers I think flymake should learn
>> > from flycheck--may as well list some here:
>> > [...]
>> > - popup a special buffer with all the error/warning/info listed
>> 
>> Please have a look at the scratch/flymake-diagnostics-buffer branch and
>> tell me what you think (perhaps comparing it to Flycheck's). The command
>> is flymake-show-diagnostics-buffer.
>> 
>> It's very naively implemented for now (and seems kinda slow).
>
> Looks good, I'd just change from using buttons to having the whole line
> be usable to navigate to the error.

Agree, makes sense. But this seems akward to do in
tabulated-list-mode. I don't mind if you beat me to it :-)

> Perhaps the biggest thing is doing
> like M-x grep and being able to M-g M-{n,p} and follow in the code
> buffer, but I suspect that ties into the next-error issue.

Yes, I believe this can of worms has to be opened eventually.

> I suspect it's the use of overlays making it slow--I don't think you
> need overlays at all for this--just store what you need in the
> tabulated-list id which IIRC gets applied to the whole line as a text
> property, which you can then use with (tabulated-list-get-id)

But it doesn't make any new overlays, if that was your idea. The
overlays used are the ones in the source buffer, where they can hardly
be avoided. Using them here seemed like the easiest and fastest way to
get to all Flymake diagnostics in a buffer.

I might have exaggerated the performance hit, since it doesn't seem so
slow to me now. Perhaps we could get some big files full of errors and
run some benchmarks with a proper backend that can be found in Flycheck,
too.

João