From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.cc-mode.general,gmane.emacs.devel Subject: Re: Reify the cc-mode-common into an actual parent mode Date: Sun, 29 May 2016 10:00:20 +0000 Message-ID: <20160529100020.GB3367@acm.fritz.box> References: <20160528113003.GA2950@acm.fritz.box> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1464516059 32638 80.91.229.3 (29 May 2016 10:00:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 29 May 2016 10:00:59 +0000 (UTC) Cc: bug-cc-mode@gnu.org, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: cc-mode-help-bounces@lists.sourceforge.net Sun May 29 12:00:44 2016 Return-path: Envelope-to: sf-cc-mode-help@m.gmane.org Original-Received: from lists.sourceforge.net ([216.34.181.88]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1b6xWV-0001zZ-3o for sf-cc-mode-help@m.gmane.org; Sun, 29 May 2016 12:00:43 +0200 Original-Received: from localhost ([127.0.0.1] helo=sfs-ml-4.v29.ch3.sourceforge.com) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1b6xWJ-0006b3-Qb; Sun, 29 May 2016 10:00:31 +0000 Original-Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1b6xWJ-0006ay-3L for cc-mode-help@lists.sourceforge.net; Sun, 29 May 2016 10:00:31 +0000 Received-SPF: neutral (sog-mx-3.v43.ch3.sourceforge.com: 208.118.235.92 is neither permitted nor denied by domain of muc.de) client-ip=208.118.235.92; envelope-from=acm@muc.de; helo=eggs.gnu.org; Original-Received: from eggs.gnu.org ([208.118.235.92]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1b6xWI-0005Nb-3T for cc-mode-help@lists.sourceforge.net; Sun, 29 May 2016 10:00:31 +0000 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b6xWB-0003e6-FL for cc-mode-help@lists.sourceforge.net; Sun, 29 May 2016 06:00:24 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.2 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:51901) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b6xWB-0003e1-Br for cc-mode-help@lists.sourceforge.net; Sun, 29 May 2016 06:00:23 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49608) by fencepost.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1b6xWA-0003Kc-P5 for bug-cc-mode@gnu.org; Sun, 29 May 2016 06:00:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b6xW7-0003dC-9Z for bug-cc-mode@gnu.org; Sun, 29 May 2016 06:00:22 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:50196) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b6xW6-0003d6-WF for bug-cc-mode@gnu.org; Sun, 29 May 2016 06:00:19 -0400 Original-Received: (qmail 11761 invoked by uid 3782); 29 May 2016 10:00:17 -0000 Original-Received: from acm.muc.de (p548C7C0D.dip0.t-ipconnect.de [84.140.124.13]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 29 May 2016 12:00:16 +0200 Original-Received: (qmail 3940 invoked by uid 1000); 29 May 2016 10:00:20 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) 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 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -0.1 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.7 SPF_NEUTRAL SPF: sender does not match SPF record (neutral) -0.8 AWL AWL: Adjusted score from AWL reputation of From: address X-Headers-End: 1b6xWI-0005Nb-3T X-BeenThere: cc-mode-help@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Bug reports, feature requests, and general talk about CC Mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: cc-mode-help-bounces@lists.sourceforge.net Xref: news.gmane.org gmane.emacs.cc-mode.general:6862 gmane.emacs.devel:204121 Archived-At: Hello, Stefan. On Sat, May 28, 2016 at 02:08:47PM -0400, Stefan Monnier wrote: > > The canonical way to create a mode derived from CC Mode is to derive > > from, say, `c-mode', call `c-add-language', then specify the values > > of the language variables which differ from those of `c-mode'. > Hmm... you don't seem to preach by example here: none of CC-mode's > predefined modes inherit from another. Indeed not. In this sense, they are "special" modes. > So I'm not sure "canonical" is the appropriate word. I think it is. Although it is certainly open to a mode hacker to go through cc-langs.el adding in values for every language variable for her new mode, it is far less troublesome to use `c-add-language', which uses an existing mode (not necessarily one of the seven "blessed" modes) as a basis. I'm not aware of anybody attempting to modify CC Mode itself to add an eigth language into it. > I also looked at some of the externally maintained major modes that rely > on CC-mode, and they generally don't seem to derive from any of your > predefined modes either. By the way, thanks for listing out these modes in cc-mode.el. I've only looked at one or two of them. csharp-mode.el, for example, does use `c-add-language'. > > There's nothing coherent about `c-mode-common'; it isn't sensible to set > > a buffer to this mode, and it would be erroneous to attempt to derive a > > mode (other than the seven within CC Mode) directly from it, since the > > language variables for the new mode wouldn't get initialised. > Currently all CC modes seem to either derive from prog-mode or from > fundamental-mode, so they all have the same need to explicitly call > things like (c-init-language-vars-for ). Using c-mode-common > doesn't make any difference in this respect. Yes. `c-init-language-vars-for' is a large part of what distinguishes one CC mode from another. This is a bit like how buffer local variables distinguish between major modes, more or less. > > modes that have them. It so happens that, at the moment, those two > > functions don't affect `c-update-modeline', so things work, but this > > executing in the wrong order is storing up trouble for the future, should > > some form in `c-mode''s :after-hook position need executing before > > `c-update-modeline'. > The fact that they don't interfere is not an accident, IMO. Possibly not. > [ BTW, I notice that define-derived-mode doesn't document the relative > order of execution of inherited :after-hooks. It's probably better > that way, admittedly. ] A fine point, but maybe you're right. > Stefan -- Alan Mackenzie (Nuremberg, Germany). ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e