From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Flymake support for C/C++ Date: Sun, 3 Jun 2018 15:45:44 +0000 Message-ID: <20180603154544.GB5860@ACM> References: <87zi8wmmhw.fsf@gmail.com> <20171012175044.GA6106@ACM> <87tvz4mcg3.fsf@gmail.com> <20171012203953.GB6106@ACM> <87infkm53o.fsf@gmail.com> <20180601210708.GA6771@ACM> <87in72p3yq.fsf@gmail.com> <20180602103317.GA4392@ACM> <87h8mlt5so.fsf@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1528040853 4444 195.159.176.226 (3 Jun 2018 15:47:33 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 3 Jun 2018 15:47:33 +0000 (UTC) User-Agent: Mutt/1.9.4 (2018-02-28) Cc: eliz@gnu.org, npostavs@users.sourceforge.net, sdl.web@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: =?iso-8859-1?Q?Jo=E3o_T=E1vora?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jun 03 17:47:29 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fPVE8-00014U-V2 for ged-emacs-devel@m.gmane.org; Sun, 03 Jun 2018 17:47:29 +0200 Original-Received: from localhost ([::1]:35680 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fPVGF-0002oC-Ku for ged-emacs-devel@m.gmane.org; Sun, 03 Jun 2018 11:49:39 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34986) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fPVG6-0002o2-P5 for emacs-devel@gnu.org; Sun, 03 Jun 2018 11:49:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fPVG3-0002Ek-Kr for emacs-devel@gnu.org; Sun, 03 Jun 2018 11:49:30 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:39679 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1fPVG3-0002DF-A0 for emacs-devel@gnu.org; Sun, 03 Jun 2018 11:49:27 -0400 Original-Received: (qmail 60191 invoked by uid 3782); 3 Jun 2018 15:49:25 -0000 Original-Received: from acm.muc.de (p5B146781.dip0.t-ipconnect.de [91.20.103.129]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 03 Jun 2018 17:49:24 +0200 Original-Received: (qmail 26406 invoked by uid 1000); 3 Jun 2018 15:45:44 -0000 Content-Disposition: inline In-Reply-To: <87h8mlt5so.fsf@gmail.com> X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x [fuzzy] X-Received-From: 193.149.48.1 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:225960 Archived-At: Hello, Joćo. On Sat, Jun 02, 2018 at 19:13:59 +0100, Joćo Tįvora wrote: > Alan Mackenzie 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).