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

[Stefan Monnier <monnier@IRO.UMontreal.CA>]

> And the setup is also done once per major mode call.  At the moment I
> can't see why these are distinct.

(setq font-lock-keywords ...) is part of font-lock's setup, whereas
(font-lock-mode 1) is part of activation.

They both needed to be executed "once per major mode call", yet
they're separate because they're not expected to be written by the same
person: one is a choice of the user, the other requires technical
knowledge which the mode's maintainer is more likely to have.

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

AFAICT the code he suggests does not make CC-mode call flymake.
It just sets a variable telling flymake how to do its job if/when it
gets enabled.

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

add-hook works just fine on an unbound variable, so there's no need for
such an `if` test.

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

Define "uncustomized": should M-x flymake-mode RET in a c-mode buffer
have a reasonable default behavior, like it does in an elisp-mode
buffer?


        Stefan