From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Flymake support for C/C++ Date: Sat, 02 Jun 2018 10:44:39 -0400 Message-ID: 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 X-Trace: blaine.gmane.org 1527950599 17806 195.159.176.226 (2 Jun 2018 14:43:19 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 2 Jun 2018 14:43:19 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: sdl.web@gmail.com, eliz@gnu.org, npostavs@users.sourceforge.net, =?windows-1252?B?Sm/jbyBU4XZvcmE=?= , emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jun 02 16:43:14 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 1fP7kN-0004VG-MG for ged-emacs-devel@m.gmane.org; Sat, 02 Jun 2018 16:43:11 +0200 Original-Received: from localhost ([::1]:60057 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fP7mU-0007TI-Sa for ged-emacs-devel@m.gmane.org; Sat, 02 Jun 2018 10:45:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46253) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fP7lt-0007SX-KO for emacs-devel@gnu.org; Sat, 02 Jun 2018 10:44:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fP7lq-0001WM-HZ for emacs-devel@gnu.org; Sat, 02 Jun 2018 10:44:45 -0400 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:37722) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fP7lq-0001Ty-Ag; Sat, 02 Jun 2018 10:44:42 -0400 Original-Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id w52EidDo014381; Sat, 2 Jun 2018 10:44:39 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 8E88D654AF; Sat, 2 Jun 2018 10:44:39 -0400 (EDT) In-Reply-To: <20180602103317.GA4392@ACM> (Alan Mackenzie's message of "Sat, 2 Jun 2018 10:33:17 +0000") X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 2 Rules triggered EDT_SA_DN_PASS=0, RV6299=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6299> : inlines <6676> : streams <1788529> : uri <2651451> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.22 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:225922 Archived-At: > And the setup is also done once per major mode call. At the moment I > can't see why these are distinct. (setq font-lock-keywords ...) is part of font-lock's setup, whereas (font-lock-mode 1) is part of activation. They both needed to be executed "once per major mode call", yet they're separate because they're not expected to be written by the same person: one is a choice of the user, the other requires technical knowledge which the mode's maintainer is more likely to have. >> I was merely pointing out that a brief "flymake" appearance in >> cc-mode.el would hardly be an exception. Of course Emacs has so many >> other parts that some of them are bound to not appear in cc-mode :-). > Calling flymake directly from C Mode would very much be an exception. > This would go against the fundamental architecture of Emacs. AFAICT the code he suggests does not make CC-mode call flymake. It just sets a variable telling flymake how to do its job if/when it gets enabled. > 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. add-hook works just fine on an unbound variable, so there's no need for such an `if` test. > 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. Define "uncustomized": should M-x flymake-mode RET in a c-mode buffer have a reasonable default behavior, like it does in an elisp-mode buffer? Stefan