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: Fri, 1 Jun 2018 21:07:08 +0000 Message-ID: <20180601210708.GA6771@ACM> References: <87zi8wmmhw.fsf@gmail.com> <20171012175044.GA6106@ACM> <87tvz4mcg3.fsf@gmail.com> <20171012203953.GB6106@ACM> <87infkm53o.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 1527887324 11422 195.159.176.226 (1 Jun 2018 21:08:44 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 1 Jun 2018 21:08:44 +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 Fri Jun 01 23:08:39 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 1fOrHq-0002tV-Tl for ged-emacs-devel@m.gmane.org; Fri, 01 Jun 2018 23:08:39 +0200 Original-Received: from localhost ([::1]:57535 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fOrJx-0007bQ-S3 for ged-emacs-devel@m.gmane.org; Fri, 01 Jun 2018 17:10:49 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47465) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fOrJq-0007bI-GU for emacs-devel@gnu.org; Fri, 01 Jun 2018 17:10:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fOrJl-00007Z-EJ for emacs-devel@gnu.org; Fri, 01 Jun 2018 17:10:42 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:38932 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1fOrJk-0008Ip-VN for emacs-devel@gnu.org; Fri, 01 Jun 2018 17:10:37 -0400 Original-Received: (qmail 79287 invoked by uid 3782); 1 Jun 2018 21:10:33 -0000 Original-Received: from acm.muc.de (p5B146CCA.dip0.t-ipconnect.de [91.20.108.202]) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 01 Jun 2018 23:10:32 +0200 Original-Received: (qmail 7500 invoked by uid 1000); 1 Jun 2018 21:07:08 -0000 Content-Disposition: inline In-Reply-To: <87infkm53o.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:225903 Archived-At: Hello, Joćo, after a delay. On Thu, Oct 12, 2017 at 22:24:59 +0100, Joćo Tįvora wrote: > Hello again, Alan. > Alan Mackenzie writes: > > Yes. It tightly couples Flymake Mode with CC Mode. It would render CC > > Mode non-functional in the absence of Flymake Mode. > If this your criteria for "tightly coupled", then it does not apply > here. c--setup-flymake simply adds to a(n abnormal) hook, using > add-hook, which is designed to be used even if the hook variable isn't > defined yet. I've had another look at your proposed cc-flymake.el. It doesn't use any CC Mode interfaces or data structures. It uses lots of flymake interfaces and data structures. It has nothing to do with CC Mode's source files; it is an integral part of flymake, and should be called something like flymake-cc.el and maintained together with the rest of flymake. This was how CC Mode's font locking originally was, before it was incorporated into the mode. It was a comparatively simple (but too simple) assemblage of font lock forms, maintained by the Emacs core team together with the rest of font-lock in font-lock.el. It wasn't until Martin Stjernholm (the previous maintainer of CC Mode) _integrated_ it into CC Mode's mechanisms that the source for it moved into CC Mode's source. 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? > (There is actually a bit of unglyness in the current patch, in which > c--setup-flymake also `defvar's and `setq-local's another obsolete > variable. I could remove that bit and come up with a pure add-hook > solution.) > > 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. > Perhaps the example that I gave you is one of the reasons. > > OK, so f-d-functions could be set in c-mode-common-hook then, > > couldn't it? > No, for the reasons that I restate below. > > I don't understand that last bit. What's the difference between > > activation and setup? > 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. > > 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? 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, ....) > > "Those two" being activation and setup? > 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. This is the sort of thing that major mode hooks are for. They maintain an arm's length relationship between unrelated parts of Emacs. > > And how would a new CC Mode hook help? > That would appease your wish for very loose coupling in that no mention > of the word "flymake" needed to appear in cc-mode.el :-). > > Would you be wanting it to be run before CC Mode is fully > > initialised? > Doesn't matter really, before the user's c-mode-common-hook is fine. Why does it need to be called before c-mode-common-hook rather than from c-mode-common-hook? > > "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. > 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. Imenu support (in cc-menus.el) isn't really part of CC Mode either, but is there by tradition. I once experimented with using CC Mode's facilities to get better recognition of C++ Mode function names, but it turned out not to be a good way to go. > > What does Flymake do, anyway? > It highlights the bits where you make mistakes as you type, or are about > to. OK. > > There's nothing in the Emacs manual > > about it, and it's doc string consists purely of boilerplate, at least > > in Emacs 25.3. > That is true, but the situation changes considerably, if not immensely, > in emacs 26 :-). I rewrote Flymake and wrote a fair amount of > documention. You can read the documentaion in Texinfo format in the > "Flymake" node (which is separate from the Emacs user manual, for now) > or just C-h f flymake-mode RET in a recent emacs-26 or master build. 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. > > But it should be loosely coupled with major modes, not tightly coupled, > > surely? > For sure, we agree. If you analyse the situation I think you'll come to > the conclusion that it is. 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. I still don't see the reason why. Hooks were designed to allow loose coupling between unrelated subsystems. Why can't we use them? > Joćo -- Alan Mackenzie (Nuremberg, Germany).