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: Sat, 2 Jun 2018 10:33:17 +0000 Message-ID: <20180602103317.GA4392@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> 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 1527935758 26222 195.159.176.226 (2 Jun 2018 10:35:58 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 2 Jun 2018 10:35:58 +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 Sat Jun 02 12:35:53 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 1fP3t2-0006ht-G9 for ged-emacs-devel@m.gmane.org; Sat, 02 Jun 2018 12:35:52 +0200 Original-Received: from localhost ([::1]:59099 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fP3ue-0003wT-2Q for ged-emacs-devel@m.gmane.org; Sat, 02 Jun 2018 06:37:32 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57091) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fP3u4-0003wO-6X for emacs-devel@gnu.org; Sat, 02 Jun 2018 06:36:57 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fP3u1-0008R0-1B for emacs-devel@gnu.org; Sat, 02 Jun 2018 06:36:56 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:36751 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1fP3u0-0008QO-M2 for emacs-devel@gnu.org; Sat, 02 Jun 2018 06:36:52 -0400 Original-Received: (qmail 99792 invoked by uid 3782); 2 Jun 2018 10:36:52 -0000 Original-Received: from acm.muc.de (p5B1464B2.dip0.t-ipconnect.de [91.20.100.178]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 02 Jun 2018 12:36:48 +0200 Original-Received: (qmail 4422 invoked by uid 1000); 2 Jun 2018 10:33:17 -0000 Content-Disposition: inline In-Reply-To: <87in72p3yq.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:225918 Archived-At: Hello, Joćo On Fri, Jun 01, 2018 at 22:54:53 +0100, Joćo Tįvora wrote: > Alan Mackenzie writes: > > cc-flymake.el is like the font locking patterns for CC Mode as they were > > ~20 years ago. It has nothing in common with CC Mode. It is likely to > > stay that way for the forseeable future. Isn't it? > Yes. No problem. Will change to flymake-cc.el And take all the symbol names out of CC Mode's namespace, please? > >> Activation is enabling the minor mode via the flymake-mode > >> function. Setup is ensuring that that activation is met with suitable > >> circunstances for the correct operation of the minor mode, in this case > >> that cc-specific "backends" are set. > > So setup is major mode dependant. > Yes. > >> > It would seem then, the activation has nothing to do with the major > >> > mode, or else it could be done in a major mode hook. What am I > >> > missing here? > >> You are not mistaken that activation has nothing to do with the major > >> mode, but you are missing that there are two steps, activation and > >> setup, that they differ in the ways I hope to have clarified above. > > The activation is done just once per Emacs session, then? > No, activation of a minor mode is done once per major-mode call. I.e > everytime you visit a c-mode buffer. 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. > > If the user needed it with CC Mode, then this activation would be a > > prime use of c-initialization-hook. > > The setup would likewise be a prime use for c-mode-common-hook, or one > > of (c-mode-hook, c++-mode-hook, java-mode-hook, ....) > No, read below. > >> No sorry, those two being the two hooks that you suggested. > >> > What do they need which is in CC Mode? > >> They need to hook on to the major mode's function. > > Maybe I've lost information over the last few months, but how is > > c-mode-common-hook not a suitable way for this to occur. > Because c-mode-common-hook, AFAIU is where the user places his own hook. > And the user might want to *remove* the flymake-cc-backend from > flymake-diagnostic-functions in that hook. Or he might want to add his > own backends, in which case he shouldn't have to worry whether that hook > element runs before or after the one that flymake-cc.el would have > placed there. 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? > Or maybe some user with some old configuration does some `setq' on the > hook var, which has always worked, that user would be surprised that > M-x flymake-mode doesn't do what his neighbour's does. Hook variables get changed with add-hook and remove-hook. Anybody using setq for this has problems anyway. [ .... ] > 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. [ .... ] > > But you're proposing tightening the coupling between flymake and CC > > Mode, you're proposing explicitly calling flymake from CC Mode, you're > > proposing putting flymake stuff inside the CC Mode source code. > Now come on! :-) I propose a line that adds a symbol to a hook, > something that will never break if flymake disappears, or is redesigned > to become a specialized brocolli cooker instead. And I've already > agreed to call the file something else that doesn't interfere with the > cc-*.el file-naming-space. CC Mode doesn't have, and shouldn't have direct interfaces with brocolli cookers. Cooks should use hooks. 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. > > I still don't see the reason why. Hooks were designed to allow loose > > coupling between unrelated subsystems. Why can't we use them? > We can, but I believe c-mode-common-hook in particular should be a > pristine nil after Emacs -Q. Perhaps I am mistaken and it's not that > common a practice, but all the major modes flymake has entered in have > followed the same guideline. 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. > Take care, > Joćo -- Alan Mackenzie (Nuremberg, Germany).