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

[Alan Mackenzie]

Hello, João, after a delay.

On Thu, Oct 12, 2017 at 22:24:59 +0100, João Távora wrote:
> Hello again, Alan.

> Alan Mackenzie <address@hidden> writes:

> > Yes.  It tightly couples Flymake Mode with CC Mode.  It would render CC
> > Mode non-functional in the absence of Flymake Mode.

> If this your criteria for "tightly coupled", then it does not apply
> here. c--setup-flymake simply adds to a(n abnormal) hook, using
> add-hook, which is designed to be used even if the hook variable isn't
> defined yet.

I've had another look at your proposed cc-flymake.el.  It doesn't use
any CC Mode interfaces or data structures.  It uses lots of flymake
interfaces and data structures.  It has nothing to do with CC Mode's
source files; it is an integral part of flymake, and should be called
something like flymake-cc.el and maintained together with the rest of
flymake.

This was how CC Mode's font locking originally was, before it was
incorporated into the mode.  It was a comparatively simple (but too
simple) assemblage of font lock forms, maintained by the Emacs core
team together with the rest of font-lock in font-lock.el.  It wasn't
until Martin Stjernholm (the previous maintainer of CC Mode)
_integrated_ it into CC Mode's mechanisms that the source for it moved
into CC Mode's source.

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?

> (There is actually a bit of unglyness in the current patch, in which
> c--setup-flymake also `defvar's and `setq-local's another obsolete
> variable. I could remove that bit and come up with a pure add-hook
> solution.)

> > thus adding to a CC Mode hook.  Major mode hooks are usually not
> > used by Emacs itself, but I'm not aware of any convention which
> > prohibits it.

> Perhaps the example that I gave you is one of the reasons.

> > OK, so f-d-functions could be set in c-mode-common-hook then,
> > couldn't it?

> No, for the reasons that I restate below.

> > I don't understand that last bit.  What's the difference between
> > activation and setup?

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

> > 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?  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, ....)

> > "Those two" being activation and setup?

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

This is the sort of thing that major mode hooks are for.  They maintain
an arm's length relationship between unrelated parts of Emacs.

> > And how would a new CC Mode hook help?

> That would appease your wish for very loose coupling in that no mention
> of the word "flymake" needed to appear in cc-mode.el

:-).

> > Would you be wanting it to be run before CC Mode is fully
> > initialised?

> Doesn't matter really, before the user's c-mode-common-hook is fine.

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

> > "Do one thing and do it well".  Let's not get into the "do it well"
> > bit here, but the "do one thing" is "edit C/C++/... buffers".  Flymake
> > would appear to be distinct from that one thing.

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

Imenu support (in cc-menus.el) isn't really part of CC Mode either, but
is there by tradition.  I once experimented with using CC Mode's
facilities to get better recognition of C++ Mode function names, but it
turned out not to be a good way to go.

> > What does Flymake do, anyway?

> It highlights the bits where you make mistakes as you type, or are about
> to.

OK.

> > There's nothing in the Emacs manual
> > about it, and it's doc string consists purely of boilerplate, at least
> > in Emacs 25.3.

> That is true, but the situation changes considerably, if not immensely,
> in emacs 26 :-). I rewrote Flymake and wrote a fair amount of
> documention. You can read the documentaion in Texinfo format in the
> "Flymake" node (which is separate from the Emacs user manual, for now)
> or just C-h f flymake-mode RET in a recent emacs-26 or master build.

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.

> > But it should be loosely coupled with major modes, not tightly coupled,
> > surely?

> For sure, we agree. If you analyse the situation I think you'll come to
> the conclusion that it is.

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.  I still
don't see the reason why.  Hooks were designed to allow loose coupling
between unrelated subsystems.  Why can't we use them?

> João

-- 
Alan Mackenzie (Nuremberg, Germany).