[Top][All Lists]

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

Re: New Flymake rewrite in emacs-26

From: João Távora
Subject: Re: New Flymake rewrite in emacs-26
Date: Tue, 10 Oct 2017 17:25:44 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.60 (gnu/linux)

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.


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

reply via email to

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