From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#21465: [PATCH] CC-modes hierarchy Date: 14 Sep 2015 19:33:49 -0000 Organization: muc.de e.V. Message-ID: <20150914193349.13729.qmail@mail.muc.de> References: NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1442259264 7463 80.91.229.3 (14 Sep 2015 19:34:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 14 Sep 2015 19:34:24 +0000 (UTC) To: 21465@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Sep 14 21:34:16 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1ZbZVz-0004AJ-QS for geb-bug-gnu-emacs@m.gmane.org; Mon, 14 Sep 2015 21:34:12 +0200 Original-Received: from localhost ([::1]:43162 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZbZVz-0005hr-0d for geb-bug-gnu-emacs@m.gmane.org; Mon, 14 Sep 2015 15:34:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34201) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZbZVv-0005hh-Na for bug-gnu-emacs@gnu.org; Mon, 14 Sep 2015 15:34:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZbZVu-0005hO-IV for bug-gnu-emacs@gnu.org; Mon, 14 Sep 2015 15:34:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:40123) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZbZVq-0005gC-QO; Mon, 14 Sep 2015 15:34:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZbZVq-0000AV-Eq; Mon, 14 Sep 2015 15:34:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Mon, 14 Sep 2015 19:34:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21465 X-GNU-PR-Package: emacs,cc-mode X-GNU-PR-Keywords: patch Original-Received: via spool by 21465-submit@debbugs.gnu.org id=B21465.1442259235634 (code B ref 21465); Mon, 14 Sep 2015 19:34:02 +0000 Original-Received: (at 21465) by debbugs.gnu.org; 14 Sep 2015 19:33:55 +0000 Original-Received: from localhost ([127.0.0.1]:60566 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZbZVi-0000A9-6g for submit@debbugs.gnu.org; Mon, 14 Sep 2015 15:33:54 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:55486) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZbZVe-00009y-K0 for 21465@debbugs.gnu.org; Mon, 14 Sep 2015 15:33:51 -0400 Original-Received: (qmail 13730 invoked by uid 3782); 14 Sep 2015 19:33:49 -0000 In-Reply-To: X-Newsgroups: gnu.emacs.bug User-Agent: tin/2.3.1-20141224 ("Tallant") (UNIX) (FreeBSD/10.1-RELEASE-p16 (amd64)) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:106552 Archived-At: In article you wrote: > Package: Emacs > Version: 25.0.50 > Any objection to the patch below? > It does the following: > - Move code common to all CC-mode major modes to a c-mode-common-mode function. > - Add new c-derivative-mode as a parent of C, C++, and ObjC, for > settings which apply to C-derived languages but not for others. > This has become necessary given that CC-mode is used nowadays as an > engine for modes which have little to do with C. > - Remove code that's redundant with what define-derived-mode does: > - set local-map > - set syntax-table > - set keymap parent > - Remove c-make-inherited-keymap, since it's not used any more. > - Fix c-after-font-lock-init so it only *moves* the function, and doesn't > accidentally add it (in case the derived mode decided to remove the function > from the hook, for example). Why? What is the point of the change? It introduces an extra layer onto the stack of major modes, but this extra layer seems to do no more than execute two forms, `(c-initialize-cc-mode t)' and `(setq abbrev-mode t)'. There is no coherence here, just two forms which happen to be in several mode's initialisation routines and put together, even though they don't form a coherent whole. If this is to be done, surely a defun rather than an extra layer of moding would be better. c-derivative-mode would really need to be called c-c-derivative mode to avoid confusion, since the prefix "c-" is just a name prefix. But again, what's this mode for? It does nothing other than add a single binding to a newly created key map. I'm not convinced there's any need to be able to treat the "C derivative" languages differently from all the others - anything you'd do in C++ Mode, you'd also be wanting to do in Java Mode in the (somewhat unusual) circumstance that you're hacking both languages. There's `c-mode-common-hook' for this. Occasionally, people ask which hook they should make their changes in. The standard recommendation is in `c-mode-common-hook' apart from (rare) things which are specific to just one language. If there are one or two extra levels of mode hook, there will be extra confusion. These new modes would add all the complexity of key maps, mode hooks, and whatever, yet not achieve any coherent abstraction. They would fragment the initialisation code. (Not that the current initialisation code is anything to write home about, but this rearrangement wouldn't be an improvement.) c-after-font-lock-init surely isn't broken. c-after-change is ALWAYS on after-change-functions. Without it, CC Mode simply wouldn't function. Or is there some way that Font Lock is called before CC Mode's initialisation, and c-after-change is somehow sneeking onto the hook twice? Or something like that. There is probably scope for getting rid of the explicit settings of the local key map, syntax table, and so on. > AFAIK this patch has no issues w.r.t compatibility since it relies on > behavior of define-derived-mode which has existed since "for ever". > But it hasn't seen much testing, admittedly (except for my own personal use). The question is, will XEmacs's define-derived-mode work? By the way, abbrev mode is used to expand "else" and "while" to themselves + re-indentation. There are one or two other keywords handled likewise. This isn't something either of us like, but doesn't seem urgent enough to get round to fixing. > Stefan [ patch read and snipped. ] -- Alan Mackenzie (Nuremberg, Germany).