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

["João Távora" <joaotavora@gmail.com>]

Hi Alan,

Alan Mackenzie <acm@muc.de> writes:

>> Yes. No problem. Will change to flymake-cc.el
> And take all the symbol names out of CC Mode's namespace, please?

Yes, certainly.

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

I think Stefan provided a fine example with font-lock.

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

The "hook" put into the hook is a lisp expression, right? Well it
happens that this lisp expression is itself adding something to another,
completely different hook. And when adding things to hooks, order
matters. There is currently no (practival) way to say "add this to the
beginning of a hook so that, no matter what the user or other libraries
do, it is always the first element".

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

I agree. But I'd rather not be the one introducing problems for these
poor souls.

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

I agree. But we're not calling into it in any way.

> Cooks should use hooks.

You should thank me for setting you up such a fine maxim :-)

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

The boundp call is *not* needed at all. And perhaps this is the source
of our misunderstanding: `add-hook' is especially designed to throw
these errors and to work before or after the hook variable is defined.

So, forgoing my beloved broccoli metaphor:

   (add-hook 'flymake-diagnostic-functions 'flymake-whatever nil t)

to any major-mode in emacs and not break the call to that mode
function. It's only when flymake-mode starts in that buffer that we'll
see its effects.  The dependency is in fact the reverse. It's flymake
that is now susceptible to any mishandling of that line in cc-mode.el

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

In this last-paragraph, we are violent agreement, word for word. 

Let's summarize. I'd to make it so that:

  Emacs -Q
  visit a .c file
  M-x flymake-mode

starts Flymake suitably in that buffer. For this I'd need to add this
line:

  (add-hook 'flymake-diagnostic-functions 'flymake-cc nil t)

to a common point in cc-mode.el. That is, in my humble opinion, the
simplest alternative, and the one I've taken with all other major modes.

Alternatively, I can add to a hook that (a) does *not* need to be nil on
Emacs -Q and (b) is run once every time a buffer is put into the major
mode cc-mode, after kill-all-local-variables.  As it seems,
c-common-mode-hook fits (b) but not (a). So I ask if there is any such
hook in cc-model.el that fits both (a) and (b)?

I see `c-initialization-hook'. I see it run from c-initialize-cc-mode,
but not unconditionally. I cannot parse the exact conditions when it
runs, but perhaps you can. Does it fit (b) and/or (a)?

João