Re: New Flymake rewrite in emacs-26

[Eli Zaretskii <eliz@gnu.org>]

> From: joaotavora@gmail.com (João Távora)
> Cc: emacs-devel@gnu.org,  sdl.web@gmail.com,  monnier@iro.umontreal.ca
> Date: Tue, 10 Oct 2017 16:09:07 +0100
> 
> No, I meant generally keep track of the backends that surfaced in this
> list and merge them into the relevant major-mode in emacs-26 (in keeping
> with your decision that they should be merged if they work reasonably
> well).

I think yes.

> >> * Should Flymake do something with next-error-function?
> >
> > I thought it already did?
> 
> It doesn't. And I should have said 'next-error' more generally. IIUC the
> place for next-error-function is for major modes, which flymake-mode
> isn't (but its proposed diagnostics buffer is).

I have no problems with Flymake keeping its hands off next-error.  But
since you've asked the question, it sounds like you are unsure whether
it's TRT?

> Anyway I think the problem is that next-error will have a hard time (if
> it doesn't already) choosing between its "next-error" source: the
> compilation, and grep occur buffers, and now the constantly updated list
> of Flymake annotations.

Yes, we had similar problems elsewhere.

> >> * There is a "Flymake diagnostics buffer" sub-feature in
> >>   scratch/flymake-diagnostics-buffer.  It is reasonably stable.  Is it
> >>   OK to merge into emacs-26?
> >
> > If it's easy to show a diff for such a merge, please do.
> 
> Patch is attached (though I don't really understand if you want to see
> the diff or rather ensure that a diff is possible and easy to revert if
> problems arise)

(I wanted to see the diffs themselves.)

Thanks, I think this can be merged to emacs-26.

> > It doesn't seem worth the hassle.  Most users will be programmers
> > anyway.
> 
> Possibly not elisp programmers, but OK.

Let's withhold the argument until we have some real problems in this
area.  IMO, the manual is small enough to host both parts of Flymake
documentation without any problem.