From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Reify the cc-mode-common into an actual parent mode Date: Sat, 28 May 2016 14:08:47 -0400 Message-ID: References: <20160528113003.GA2950@acm.fritz.box> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1464458954 5868 80.91.229.3 (28 May 2016 18:09:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 28 May 2016 18:09:14 +0000 (UTC) Cc: bug-cc-mode@gnu.org, emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat May 28 20:09:05 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1b6ifY-0003rd-Mx for ged-emacs-devel@m.gmane.org; Sat, 28 May 2016 20:09:04 +0200 Original-Received: from localhost ([::1]:53876 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b6ifX-0000FY-Qt for ged-emacs-devel@m.gmane.org; Sat, 28 May 2016 14:09:03 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51349) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b6ifR-0000FD-Jb for emacs-devel@gnu.org; Sat, 28 May 2016 14:08:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b6ifP-0008Vl-G2 for emacs-devel@gnu.org; Sat, 28 May 2016 14:08:56 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:6935) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b6ifI-0008Uf-K6; Sat, 28 May 2016 14:08:48 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A+FgA731xV//v1SC1cgxCEAoVVwwsEAgKBPD0QAQEBAQEBAYEKQQWDXQEBAwFWIwULCw4mEhQYDSSINwjPIwEBAQEGAgEfizqFBQeELQWZbYF3gzMTjgODfoNZI4QUIoJ4AQEB X-IPAS-Result: A0A+FgA731xV//v1SC1cgxCEAoVVwwsEAgKBPD0QAQEBAQEBAYEKQQWDXQEBAwFWIwULCw4mEhQYDSSINwjPIwEBAQEGAgEfizqFBQeELQWZbYF3gzMTjgODfoNZI4QUIoJ4AQEB X-IronPort-AV: E=Sophos;i="5.13,465,1427774400"; d="scan'208";a="239802891" Original-Received: from 45-72-245-251.cpe.teksavvy.com (HELO pastel.home) ([45.72.245.251]) by ironport2-out.teksavvy.com with ESMTP; 28 May 2016 14:08:48 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id DBF336445E; Sat, 28 May 2016 14:08:47 -0400 (EDT) In-Reply-To: <20160528113003.GA2950@acm.fritz.box> (Alan Mackenzie's message of "Sat, 28 May 2016 11:30:03 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:204113 Archived-At: > 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. So I'm not sure "canonical" is the appropriate word. 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. > 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. > 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. [ 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. ] Stefan