Re: New Flymake rewrite in emacs-26

[João Távora]

Eli Zaretskii <address@hidden> writes:

> I think yes.

OK, IIUC we have copyright assignments for every author besides me
(that’s Lele and Mark). So I invite these people to cross-check their
work against new API documentation, and merge it to emacs-26.

It would be nice to have a backend capable of checking Emacs C sources
with GCC and without any extra configurations. To solve the problem with
setting proper GCC flags, perhaps the .dir-locals file can be used. Or
perhaps some other method can be used to infer flags from a Makefile or
some other source.

Likewise for a perl backend, which should be even simpler.

>> >> * 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?

Yes. I don’t use next-error at all, so I don’t think I’m a good person
to implement this kind of UI integration (rather, I’ll implement it 
iff someone provides precise requires).

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

Done

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

Mainly I thought it would increase awareness of the Flymake API to
major-mode-writers, but I agree with your argument.