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

[Alan Mackenzie <acm@muc.de>]

Hello, João

On Fri, Jun 01, 2018 at 22:54:53 +0100, João Távora wrote:

> Alan Mackenzie <acm@muc.de> writes:

> > cc-flymake.el is like the font locking patterns for CC Mode as they were
> > ~20 years ago.  It has nothing in common with CC Mode.  It is likely to
> > stay that way for the forseeable future.  Isn't it?

> Yes. No problem. Will change to flymake-cc.el

And take all the symbol names out of CC Mode's namespace, please?

> >> Activation is enabling the minor mode via the flymake-mode
> >> function. Setup is ensuring that that activation is met with suitable
> >> circunstances for the correct operation of the minor mode, in this case
> >> that cc-specific "backends" are set.

> > So setup is major mode dependant.

> Yes.


> >> > It would seem then, the activation has nothing to do with the major
> >> > mode, or else it could be done in a major mode hook.  What am I
> >> > missing here?

> >> You are not mistaken that activation has nothing to do with the major
> >> mode, but you are missing that there are two steps, activation and
> >> setup, that they differ in the ways I hope to have clarified above.

> > The activation is done just once per Emacs session, then?

> No, activation of a minor mode is done once per major-mode call. I.e
> everytime you visit a c-mode buffer.

And the setup is also done once per major mode call.  At the moment I
can't see why these are distinct.  I'll try reading some earlier posts
again, maybe this will help.

> > If the user needed it with CC Mode, then this activation would be a
> > prime use of c-initialization-hook.

> > The setup would likewise be a prime use for c-mode-common-hook, or one
> > of (c-mode-hook, c++-mode-hook, java-mode-hook, ....)

> No, read below.

> >> No sorry, those two being the two hooks that you suggested.

> >> > What do they need which is in CC Mode?

> >> They need to hook on to the major mode's function.

> > Maybe I've lost information over the last few months, but how is
> > c-mode-common-hook not a suitable way for this to occur.

> Because c-mode-common-hook, AFAIU is where the user places his own hook.
> And the user might want to *remove* the flymake-cc-backend from
> flymake-diagnostic-functions in that hook.  Or he might want to add his
> own backends, in which case he shouldn't have to worry whether that hook
> element runs before or after the one that flymake-cc.el would have
> placed there.

The flymake hook which would be put into c-mode-common-hook should be
designed such that it doesn't matter whether it is executed before or
after the user's other hook functions.  A user doing something like
removing something from flymake-diagnostic-functions will surely be doing
this in flymake-mode-hook, no?

> Or maybe some user with some old configuration does some `setq' on the
> hook var, which has always worked, that user would be surprised that
> M-x flymake-mode doesn't do what his neighbour's does.

Hook variables get changed with add-hook and remove-hook.  Anybody using
setq for this has problems anyway.

[ .... ]

> I was merely pointing out that a brief "flymake" appearance in
> cc-mode.el would hardly be an exception. Of course Emacs has so many
> other parts that some of them are bound to not appear in cc-mode :-).

Calling flymake directly from C Mode would very much be an exception.
This would go against the fundamental architecture of Emacs.

[ .... ]

> > But you're proposing tightening the coupling between flymake and CC
> > Mode, you're proposing explicitly calling flymake from CC Mode, you're
> > proposing putting flymake stuff inside the CC Mode source code.

> Now come on! :-) I propose a line that adds a symbol to a hook,
> something that will never break if flymake disappears, or is redesigned
> to become a specialized brocolli cooker instead.  And I've already
> agreed to call the file something else that doesn't interfere with the
> cc-*.el file-naming-space.

CC Mode doesn't have, and shouldn't have direct interfaces with brocolli
cookers.  Cooks should use hooks.

And just a small point, your proposed patch is lacking clauses like

   (if (boundp 'flymake-diagnostic-functions) ....)

to check that flymake mode actually exists, and an assignment to it won't
throw an error if it doesn't exist.

> > I still don't see the reason why.  Hooks were designed to allow loose
> > coupling between unrelated subsystems.  Why can't we use them?

> We can, but I believe c-mode-common-hook in particular should be a
> pristine nil after Emacs -Q.  Perhaps I am mistaken and it's not that
> common a practice, but all the major modes flymake has entered in have
> followed the same guideline.

c-mode-common-hook should, indeed must, be nil on Emacs -Q.  And flymake
mode must equally remain disabled until explicitly enabled (e.g. by a
user customisation).  The whole point of -Q is to get an uncustomised
vanilla Emacs.

> Take care,
> João

-- 
Alan Mackenzie (Nuremberg, Germany).