From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Flymake support for C/C++ Date: Sat, 02 Jun 2018 19:13:59 +0100 Message-ID: <87h8mlt5so.fsf@gmail.com> 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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1527963193 24800 195.159.176.226 (2 Jun 2018 18:13:13 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 2 Jun 2018 18:13:13 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: eliz@gnu.org, npostavs@users.sourceforge.net, sdl.web@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jun 02 20:13:08 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 1fPB1X-0006I6-MQ for ged-emacs-devel@m.gmane.org; Sat, 02 Jun 2018 20:13:07 +0200 Original-Received: from localhost ([::1]:60689 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fPB3e-0003Mm-Gu for ged-emacs-devel@m.gmane.org; Sat, 02 Jun 2018 14:15:18 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47216) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fPB2c-0003Kj-BT for emacs-devel@gnu.org; Sat, 02 Jun 2018 14:14:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fPB2b-0000Ph-7W for emacs-devel@gnu.org; Sat, 02 Jun 2018 14:14:14 -0400 Original-Received: from mail-wm0-x244.google.com ([2a00:1450:400c:c09::244]:38269) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fPB2U-0000M9-R0; Sat, 02 Jun 2018 14:14:07 -0400 Original-Received: by mail-wm0-x244.google.com with SMTP id m129-v6so7591513wmb.3; Sat, 02 Jun 2018 11:14:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=MZAJTBAXPe8H1QMpM7Bl54R38v76WDqvOS7F+HZ0O8w=; b=mCaGjd+bITSAwIDHqXlxO529i2CKT7Tonl8SqZMl4HmF/J8hJawZQvmB9xVQ0T75Y8 4CkrUHk6R1chBZO8wmQk7chIVWcxouYnQKUnuAw8wu5K97TbvbEBxHJEmQknL8/B6XNa VTRp7XkWeZcdtPiMZJmc/Cmku4/e3mWRyUJT6MfCYIDblQsSDIbyzUVAJ/LlJx8jY4PI Zjqi+pSshbSY1ARo+upIMBKm6Drlusa48TPvn4rmZ5krmiPMbP3dy1FfETQrbwUCk05G eJan0wycgjrNMbpy5BlCXBfUlF9jirQklWUbZawrfs2XxandtST9bTjpYqgWkAd7AHh7 5VUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=MZAJTBAXPe8H1QMpM7Bl54R38v76WDqvOS7F+HZ0O8w=; b=FvgF/juqbuxtHZeE+kWiUH1B0IgddMyWY/YKL8mj9FSSB2sETjFKxqkgKirW1zjqrQ mcB9jtyuhAeepeyvgan/8ImZKDOZHQPcB9FxfjQEdeJDI5Xg8geUBOkMZtBggXpnTRBw 7dyxlXZYrwFz2/lscB7dWwvyzMtFBgVLqW1IX//avxr6Ga3gX5VqfghaWzD2scByttxn Qk7njJze3CJOBGXExLuM6yRhsnZ2eJYo7SWP/wrUkCTX1il+Rl1c07laBDg9Uz0Au7Zn +559POeRYDKSX7YSqaucLMvWkyNpHQI20KauJtUEkvCvn5LeDcImAzyOsRTpO0ENZ2p5 N7eQ== X-Gm-Message-State: APt69E1k/W4EQVmt5x3hKSERlJ131YoimTsLtaOTE39vcqthDNHJR6g8 yGLh3P1f50MTC1o8rNt9yRg= X-Google-Smtp-Source: ADUXVKITAbx3F+4K5gEew++DIKXkLWJqFmbNjdn81AbqEtUQvem02rz79RXwLW3+f3o8HKSH2lLJaQ== X-Received: by 2002:a1c:f52:: with SMTP id 79-v6mr5739699wmp.24.1527963245590; Sat, 02 Jun 2018 11:14:05 -0700 (PDT) Original-Received: from lolita.yourcompany.com (193.105.108.93.rev.vodafone.pt. [93.108.105.193]) by smtp.gmail.com with ESMTPSA id e63-v6sm3501295wma.46.2018.06.02.11.14.03 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 02 Jun 2018 11:14:04 -0700 (PDT) In-Reply-To: <20180602103317.GA4392@ACM> (Alan Mackenzie's message of "Sat, 2 Jun 2018 10:33:17 +0000") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:400c:c09::244 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:225929 Archived-At: Hi Alan, 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. > 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. > 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. > 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 :-) > 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. 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 > 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 violent agreement, word for word.=20 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. 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)? Jo=C3=A3o