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: Thu, 12 Oct 2017 20:39:53 +0000 Message-ID: <20171012203953.GB6106@ACM> References: <87zi8wmmhw.fsf@gmail.com> <20171012175044.GA6106@ACM> <87tvz4mcg3.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 1507840952 27923 195.159.176.226 (12 Oct 2017 20:42:32 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 12 Oct 2017 20:42:32 +0000 (UTC) User-Agent: Mutt/1.7.2 (2016-11-26) 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 Thu Oct 12 22:42:28 2017 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 1e2kJB-0005x3-I8 for ged-emacs-devel@m.gmane.org; Thu, 12 Oct 2017 22:42:21 +0200 Original-Received: from localhost ([::1]:47145 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e2kJJ-0004lR-1r for ged-emacs-devel@m.gmane.org; Thu, 12 Oct 2017 16:42:29 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39055) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e2kJ5-0004jZ-PP for emacs-devel@gnu.org; Thu, 12 Oct 2017 16:42:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e2kJ2-0002ZC-K4 for emacs-devel@gnu.org; Thu, 12 Oct 2017 16:42:15 -0400 Original-Received: from ocolin.muc.de ([193.149.48.4]:29658 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1e2kJ2-0002Uo-DG for emacs-devel@gnu.org; Thu, 12 Oct 2017 16:42:12 -0400 Original-Received: (qmail 46552 invoked by uid 3782); 12 Oct 2017 20:42:08 -0000 Original-Received: from acm.muc.de (p548C7111.dip0.t-ipconnect.de [84.140.113.17]) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 12 Oct 2017 22:42:06 +0200 Original-Received: (qmail 8423 invoked by uid 1000); 12 Oct 2017 20:39:53 -0000 Content-Disposition: inline In-Reply-To: <87tvz4mcg3.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.4 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:219429 Archived-At: Hello again, Joćo. On Thu, Oct 12, 2017 at 19:46:20 +0100, Joćo Tįvora wrote: > Hi Alan, > Alan Mackenzie writes: > > I must admit not to being too keen on CC Mode changing like this; it > > would spoil the unity of purpose of the mode. I've glanced through the > > new code, but can't quite see why it needs to be an integral part of CC > > Mode. > Does setting a variable in the mode function make it an "integral part"? Yes. It tightly couples Flymake Mode with CC Mode. It would render CC Mode non-functional in the absence of Flymake Mode. Distinct functionalities should not be tightly coupled. > > What is stopping the needed setup and initialisation being in a > > function to be added to one of the mode's hooks: say c-mode-common-hook, > > or even c-initialization-hook (which are documented in the CC Mode > > manual)? > I may be wrong, but I thought hooks were reserved for the user and > should be empty by default. But it would surely be a user action which would enable flymake-mode, thus adding to a CC Mode hook. Major mode hooks are usually not used by Emacs itself, but I'm not aware of any convention which prohibits it. > But even if they weren't I don't think it would work: > c-initialization-hook doesn't work, as flymake-diagnostic-functions is > a hook which needs a buffer-local value. OK, so f-d-functions could be set in c-mode-common-hook then, couldn't it? > c-mode-common-hook is where a user would turn on `flymake-mode'. I, for > example, have this in my .emacs, which is the recommended way to turn on > a minor mode: > (add-hook 'c-mode-common-hook 'flymake-mode) > If the setup is also moved to c-mode-common-hook, then this won't work > (because flymake-mode activation comes before its setup). I don't understand that last bit. What's the difference between activation and setup? 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? > > If there is any reason why it couldn't work on a CC Mode hook, > Absolutely no reason, but those two don't seem to fit. Perhaps some new > hook run before c-mode-common-hook. "Those two" being activation and setup? What do they need which is in CC Mode? And how would a new CC Mode hook help? Would you be wanting it to be run before CC Mode is fully initialised? > > I'd far rather solve that reason (thus making the solution available > > for other libraries too, and pres I don't understand what the boundaries of that "unity" are, .... "Do one thing and do it well". Let's not get into the "do it well" bit here, but the "do one thing" is "edit C/C++/... buffers". Flymake would appear to be distinct from that one thing. What does Flymake do, anyway? There's nothing in the Emacs manual about it, and it's doc string consists purely of boilerplate, at least in Emacs 25.3. > .... but I do understand cc-mode.el seems to be a special citizen in > Emacs major-mode-land. :-) As a matter of interest CC Mode consists of ~14 files, one of which is cc-mode.el. > Anyway Flymake wants to be a part of the global infrastructure for major > modes, which includes setting variables for recent "fancy" stuff like > ElDoc (eldoc-documentation-function), and older stuff like newcomment.el > (comment-*), to give just two examples. My patch does the same for > Flymake and flymake-diagnostic-functions. But it should be loosely coupled with major modes, not tightly coupled, surely? > Joćo -- Alan Mackenzie (Nuremberg, Germany).