Re: [PATCH] Flymake support for C/C++

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

Hello Guillaume, Reuben,

I hope you don't mind that I am replying to you both in the same
message.
        
Reuben Thomas <rrt@sc3d.org> writes:

> On 14 October 2017 at 09:00, Eli Zaretskii <eliz@gnu.org> wrote:
> ​See
> ​http://www.flycheck.org/en/latest/user/flycheck-versus-flymake.html#flycheck-versus-flymake​

That page is now completely outdated. If you have a serious interest in
updating it, I can provide you with information about the new Flymake
that isn't already in its manual. Otherwise, please don't advertise a
misleading comparison.

>>  don't see why should we object to such an effort, when one of our
>>  major goals is to provide a modern program development environment.
> ​Because with Flycheck this is already accomplished.

I believe it is generally naive to think such a thing.  But
specifically, I've had a look at flycheck.el and (again, if you are
really interested) I am willing to debate why I think parts of its
implementation are inferior to my rewrite of Flymake.

guillaume papin <guillaume.papin@epitech.eu> writes:

> flycheck used to invoke Make, at least for checking Makefiles.
> However they removed this feature[1],
> after user complained about the security implication of invoking Make[2] [3].

flymake-mode isn't (yet) turned on by default on visiting a file, so I
think there aren't these implications yet (I might be overseeing
others).

> To answer your questions, which weren't addressed to me but I will
> share what I know:

No problem, this is always welcome.

> Out-of-the-box, Flycheck does not seem to infer the flags for GNU Hello.

I suppose it's safe to say it doesn't try to infer flags for any
project.  So here's one (apparently useful) thing that Flymake might do
that Flycheck doesn't. My point obviously being that there is no "end of
History" for on-the-fly buffer checkers (or for anything by that
matter), there are always things to work on.

> M-x customize-variable RET flycheck-gcc-args RET can be sufficient, the other options preceded this generic option.
> However settings the option per file manually does not really scale
> IMHO.

In Flymake/Emacs, you would use .dir-locals to set it for the dir. I'd
be surprised to learn that doesn't work for Flycheck, too.

> Also, many other features would benefit from knowing these

That's my idea too.

> I'm not sure that the best solution is for flymake to invent it's own
> way of getting the compile options.

I, on the contrary, am quite sure it is not.  But this is precisely the
point of Flymake being in Emacs: it means that functionality that begins
by being specific to a package can more easily be refactored so it is
used by other parts of Emacs.

This also works in the reverse direction: Flymake can benefit early from
improvements done to other parts of Emacs.  Perhaps Flymake will take
earlier advantage from improvements to project.el backends (which are,
in my opinion, the natural place for such a flag-guessers to live).  And
Flymake can be the catalyst for improvements to other packages, like
checkdoc or Flyspell, to name just two.

Finally, being in Emacs also means it gets the care and attention of a
very talented group of programmers that share the common goal of
improving GNU and Emacs as a whole.

João