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

[Alan Mackenzie <acm@muc.de>]

Hello, João.

On Sat, Jun 02, 2018 at 19:13:59 +0100, João Távora wrote:

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

Thanks!

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

Yes.  That was helpful.  Thanks, Stefan!

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

Fair enough!

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

Indeed!  Thanks for being my "straight man".  :-)

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

OK.  But a little way down there's a

    (setq-local flymake-proc-allowed-file-name-masks nil)

, which will create a buffer-local free variable if the variable doesn't
already exist.  This is somewhat untidy.  Not so important, either.

> 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

I think I now understand things better.  CC Mode deals with the syntax
(and, to a limited extent, the semantics) of C, C++, Java, .....
flycheck Mode deals with the embedding of the C, C++, ... build systems
in their environment - things like the compiler used, a command line to
activate parsing of the source, the parsing of its error output, things
like this.

There is NOTHING in common between these two realms, beyond the identity
of the major mode.  There is no other useful information CC Mode can
pass to flymake-mode.  But the major mode is a property of the buffer,
and thus not info that CC Mode can usefully supply.

There is nothing CC Mode can tell flymake-mode in any function call.
Looking at the proposed patch, the arguments passed over in
c--setup-flymake are flymake details, not CC Mode details.

Surely the same applies to all the other major modes with flymake
support.  Looking at elisp.el and perl.el, for example, and the proposed
CC Mode patch, there would seem to be a generic similarity between the
flymake bits in all of them.  This smells of code duplication, which, if
I'm right, is not a Good Thing.  These flymake pieces have much more to
do with eachother than with the major modes they're embedded in.

How about putting all these details in an alist in flymake-mode.el, the
key being the major mode?  That might then enable you to combine
cc-flymake and perl-flymake, etc., into a single function/macro with
more arguments than the current functions take, thus condensing the code
and making it easier to maintain.

> > 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 in violent agreement, word for word. 

Excellent!

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

As I suggested above, why not simply build that information into
flymake.el at build (or customisation) time without troubling CC Mode at
all?

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

c-initialization-hook is run exactly once, when CC Mode itself is
loaded.  Maybe this could be useful here.

> João

-- 
Alan Mackenzie (Nuremberg, Germany).