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

[João Távora]

Hi Alan,

Alan Mackenzie <address@hidden> 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

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

> 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.  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 is neighbour's does.

> Why does it need to be called before c-mode-common-hook rather than from
> c-mode-common-hook?

>> Ah, I so do agree with you Alan... and let's get not into the million
>> ways Emacs is already the kitchen sink. Flymake can be as useful to a
>> pretty broad definition of "editing" as font-locking, or imenu, or
>> outline.el, or supporting add-log-current-defun-function. All those
>> things that really aren't "editing", but help you edit.
>
> As do flyspell, compile mode, trailing space mode (or whatever it's
> called), #ifdef mode (or whatever that's properly called), and any
> number of other minor modes.  None of them make an appearance in the CC
> Mode source code, but are frequently enabled in major mode hooks.
> outline.el doesn't either.

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

> This is good.  But the intro page to the flymake manual still says
>
>     This manual is for GNU Flymake (version 0.3, April 2004)
>
> :-(  That could perhaps use an update.

Riiiight. Gotta fix that, thanks for reminding me.

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

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

Take care,
João