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: Fri, 01 Jun 2018 22:54:53 +0100 Message-ID: <87in72p3yq.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> 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 1527890029 27324 195.159.176.226 (1 Jun 2018 21:53:49 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 1 Jun 2018 21:53:49 +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 Fri Jun 01 23:53:44 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 1fOrzU-000701-CS for ged-emacs-devel@m.gmane.org; Fri, 01 Jun 2018 23:53:44 +0200 Original-Received: from localhost ([::1]:57611 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fOs1Y-0004vt-3B for ged-emacs-devel@m.gmane.org; Fri, 01 Jun 2018 17:55:52 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38481) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fOs0q-0004vY-Ml for emacs-devel@gnu.org; Fri, 01 Jun 2018 17:55:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fOs0n-0002HJ-K3 for emacs-devel@gnu.org; Fri, 01 Jun 2018 17:55:08 -0400 Original-Received: from mail-wm0-x244.google.com ([2a00:1450:400c:c09::244]:40603) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fOs0i-0001tR-QC; Fri, 01 Jun 2018 17:55:01 -0400 Original-Received: by mail-wm0-x244.google.com with SMTP id x2-v6so4785823wmh.5; Fri, 01 Jun 2018 14:55:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:in-reply-to:references:user-agent:date :message-id:mime-version:content-transfer-encoding; bh=OmUwxkGRFQ6A8pd5eweKNkqBn8ynplgu34z1ArQw7KA=; b=sdYZBWFpbByL3ZLGtSGrrOc1XZnmjeXAGwCFyqWcsovwxsoGp5+iIduV0m7L6xw681 apfIoK/eQ9toD50IiwEoLkooeHg6FjaP/2chDqukmYpAVVrhtjg9IAAHNAxLPG2rigX3 O1L1fmW/WX24yVmLiqsmE3KJLgo9zxl5pBcJEM6RavSdm0IRB1Zw3RYY1c97ZsqvVWWM PctHBoeEfShoPlWbs+BCaFuX7sv+oMdQlh2c43/NXEkD8PZj6+b6ctxF9MVP2CFuLKO3 u/rtA2NQTDyQuNvA7GzI3kBkITfRXc6/iLQHd3gzLDToboGseMdxHAWG7cePdQqc19I9 ding== 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:in-reply-to:references :user-agent:date:message-id:mime-version:content-transfer-encoding; bh=OmUwxkGRFQ6A8pd5eweKNkqBn8ynplgu34z1ArQw7KA=; b=YopZfqyVjEJ/aqFDHT2KCwWjtbj31xcsTtOCm7FqgUvT10A0/D6sThg9XnJHR+9DDQ TA6SQCifczluiSzTaJksWJMhjO4B8cVGn7uena0L7ntKBw7ZYOxz9psWSOti+WAj2w6y N0q+7GXvYWzlL8VhqmwRqWtJGbXAl9vDYgE6JEwH0XvUQhhO7ChZ/0zEMMEZE9BB/0RP OmOHWeowc4WNSndzeBEswPDQD7fAeuwf4NP+ciQfbrZ9cnhmauH0HBHHl0NYwTUnF8Da ujR9UKTBb9WS1VJDVXYNdGnFY14qwgfaMJUN/zZ+SsGCbuEQIN2UMVtonDHiIxh/0+oP Bf5A== X-Gm-Message-State: ALKqPwe8cf5UjzKs4hxwI6HB0Cau2Gr7xSA/c9tsWnEiHaAByreut+Mo 9GfWjeOH+9jx/+vjG6bFua4= X-Google-Smtp-Source: ADUXVKIspJ91dsrAFe1Yvbye9byPhSO6it4MbKnpopZMq/rYZwRuxZdW7ck8h6gcBb8GvBWjHWOilg== X-Received: by 2002:a1c:630a:: with SMTP id x10-v6mr4123895wmb.93.1527890099453; Fri, 01 Jun 2018 14:54:59 -0700 (PDT) Original-Received: from lolita.yourcompany.com (188.139.62.94.rev.vodafone.pt. [94.62.139.188]) by smtp.gmail.com with ESMTPSA id q7-v6sm36094658wrf.0.2018.06.01.14.54.57 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 01 Jun 2018 14:54:58 -0700 (PDT) In-Reply-To: <20180601210708.GA6771@ACM> (Alan Mackenzie's message of "Fri, 1 Jun 2018 21:07:08 +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:225904 Archived-At: Hi Alan, 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 >> 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. > 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. 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 is neighbour's does. > Why does it need to be called before c-mode-common-hook rather than from > c-mode-common-hook? >> Ah, I so do agree with you Alan... and let's get not into the million >> ways Emacs is already the kitchen sink. Flymake can be as useful to a >> pretty broad definition of "editing" as font-locking, or imenu, or >> outline.el, or supporting add-log-current-defun-function. All those >> things that really aren't "editing", but help you edit. > > As do flyspell, compile mode, trailing space mode (or whatever it's > called), #ifdef mode (or whatever that's properly called), and any > number of other minor modes. None of them make an appearance in the CC > Mode source code, but are frequently enabled in major mode hooks. > outline.el doesn't either. 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 :-). > This is good. But the intro page to the flymake manual still says > > This manual is for GNU Flymake (version 0.3, April 2004) > > :-( That could perhaps use an update. Riiiight. Gotta fix that, thanks for reminding me. > 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. > 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. Take care, Jo=C3=A3o