emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: João Távora
Subject: Re: [PATCH] Flymake support for C/C++
Date: Sun, 03 Jun 2018 17:28:20 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Hello Alan,

Alan Mackenzie <address@hidden> writes:

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

Very much so. I will remove this line, it's not needed.

> How about putting all these details in an alist in flymake-mode.el,
> the key being the major-mode

That's something that flymake-mode.el had *before* the Emacs 26.1
redesign.  It's a natural approach when a package lives outside Emacs,
but obviously, suffers from the big drawback that flymake-mode.el itself
must be changed everytime a major-mode is added to Emacs, or to GNU
ELPA, or anywhere in the emacs ecosphere.

>>   (add-hook 'flymake-diagnostic-functions 'flymake-cc nil t)
>
> As I suggested above, why not simply build that information into
> flymake.el at build (or customisation) time without troubling CC Mode at
> all?

No, for the reasons detailed above. As it stands, I propose to add that
single to cc-mode.el.  As argued already:

1. it is much shorter than, say cc-mode's configuration of imenu, or
font-lock

2. in contrast to those two, because it uses add-hook, it will never
break or error even if flymake-mode.el is removed, reworked, etc..

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

Unfortunately, it doesn't meet criteria (b), so I can't use it.

João



reply via email to

[Prev in Thread] Current Thread [Next in Thread]