From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Further CC-mode changes Date: Fri, 12 Sep 2014 23:59:48 +0000 Message-ID: <20140912235948.GA4045@acm.acm> References: <53632C6F.5070903@dancol.org> <20140511211351.GC2759@acm.acm> <536FEA43.5090402@dancol.org> <20140516175226.GB3267@acm.acm> <537653A0.2070109@dancol.org> <20140518213331.GB2577@acm.acm> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1410566745 26478 80.91.229.3 (13 Sep 2014 00:05:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 13 Sep 2014 00:05:45 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Sep 13 02:05:38 2014 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 1XSaqP-0001Mp-3N for ged-emacs-devel@m.gmane.org; Sat, 13 Sep 2014 02:05:37 +0200 Original-Received: from localhost ([::1]:47737 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XSaqO-00085s-Bb for ged-emacs-devel@m.gmane.org; Fri, 12 Sep 2014 20:05:36 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37688) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XSaq7-0007kv-Bx for emacs-devel@gnu.org; Fri, 12 Sep 2014 20:05:26 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XSapz-0002AG-Ro for emacs-devel@gnu.org; Fri, 12 Sep 2014 20:05:19 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:57534 helo=mail.muc.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XSapz-0002A8-EY for emacs-devel@gnu.org; Fri, 12 Sep 2014 20:05:11 -0400 Original-Received: (qmail 95154 invoked by uid 3782); 13 Sep 2014 00:05:09 -0000 Original-Received: from acm.muc.de (pD951AC47.dip0.t-ipconnect.de [217.81.172.71]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 13 Sep 2014 02:05:08 +0200 Original-Received: (qmail 5192 invoked by uid 1000); 12 Sep 2014 23:59:48 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 8.x X-Received-From: 193.149.48.1 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:174259 Archived-At: Hello, Stefan. On Thu, Sep 11, 2014 at 09:55:29AM -0400, Stefan Monnier wrote: > While waiting for your guidance as to which parts of my patches need to > be reverted and why, here's some candidate patch which (contrary to the > one you reverted) actually changes the code's behavior. > It's to be applied on top of the ones you removed (tho since the ones > you remove are mostly cosmetic, it shouldn't make much of a difference). > Questions: > - should C-c C-n and friends be moved to c-derivative-mode-map > (AFAIK neither Java nor IDL nor Pike have CPP conditionals)? No. Less disruptive is either to remove these bindings from c-mode-base-map and put them in c-mode-map etc., or to splat them out from java-mode-map, etc., as is done in awk-mode-map. This is a bug, I suppose, but a tiny one - attempting C-c C-n in Java Mode throws an error immediately. > - I notice that all cc-mode enable abbrev-mode except for idl-mode. > Was that on purpose or is it just accidental? Probably deliberate. IDL Mode doesn't have keywords like "else", as far as I'm aware. I'm also not aware of anyone using IDL Mode, there having been no bug reports for it for many years, if ever. > - BTW, I think it would be better not to enable abbrev-mode (let it be > a user's choice). IIUC CC-mode relies on abbrev-mode internally > for some of its electric-indent functionality, so we'd have to use > some other approach (e.g. a post-self-insert-hook). I tend to agree, having been a bit disgusted myself when I discovered how "else" and friends were being electrically indented. after-change-functions might be better here, since it's more general, and also better supported. > This is not really tested, especially not on XEmacs, but AFAIK it > doesn't depend on any feature specific to a particular Emacs version. "This"?? > Stefan > - Move awk-mode's actual definition to cc-awk so as to get rid of the > (require 'cc-awk) and the ":syntax-table nil" hack. Would leave traps for maintainers, and break uniformity between the modes. Putting all the mode defuns together was a deliberate decision, though I can't remember whether it was Martin or me that made it. This change wouldn't enhance functionality or maintainability. > - make awk-mode use syntax-propertize when available. Why? It's a lot of work to change, syntax-propertize is only available in relatively recent versions of GNU Emacs, and the documentation suggests that syntax-propertize is not called after buffer changes in general, the documentation not being entirely clear on this point. This change wouldn't enhance functionality or maintainability. > - Use define-derived-mode's built-in keymap inheritance rather than > c-make-inherited-keymap. c-make-inherited-keymap is simpler. This change wouldn't enhance functionality or maintainability. > - initialize c-mode-base-map in its defvar. An inconsequential change that wouldn't enhance functionality or maintainability. It's work to make, though. > - fix c-after-font-lock-init so it doesn't accidentally add > a c-after-change which wasn't there to begin with. ??? There's nothing broken here, surely? > - Run c-update-modeline from after-change-major-mode-hook and > hack-local-variables-hook rather than from the major mode function. > This lets us fix the bug where c-mode-hook is run twice and saves us > from having to define c-run-mode-hooks. after-change-major-mode-hook is a GNU Emacs speciality. The major mode functions (and several commands, of course) are the natural places to call c-update-modeline from. How about enhancing define-derived-mode so that modes that have things to do after running their hooks can do them? That would surely be a simple change? > - make c-mode-common into an actual parent mode. There is a naming problem > since we have c-mode-base-map for the "parent map" but > c-mode-common-hook for the "parent hook", and also because this "mode" > doesn't end in "-mode", but I think we can live with it. Why? There is no such mode c-mode-common; nobody's ever going to have a buffer in this mode; it would merely be a software-engineeringy way of achieving... what? It would add complexity where none is warranted. > - add a new parent mode c-derivative-mode which can hold those things > common to c, c++, and objc (i.e. languages which include C as a subset). > I was tempted to simply use c-mode as the parent for c++-mode and > objc-mode, but this would be a lot more intrusive and it would force > the presence of a "C" menu in both C++ and ObjC modes (we could fix > that for Emacs, but I'm not sure how to do it for XEmacs, and it > doesn't seem worth the trouble). Why? What complixity would c-derivative-mode save that would justify its existence? I think your last clause is true for the entire paragraph. [ Snipped ~750 lines of patch. ] In that patch, your assumptions about what AWK Mode needs in c-{before,after}-change were incorrect. There are likely other bugs in the patch too. Remember, a previous, "simple, cosmetic" change, using define-derived-mode to derive CC Mode's modes from prog-mode, introduced two bugs, each of which took several hours to track down. One of these is still unfixed. It has taken me several hours to study your email and answer it. Your patch is all about rearranging the deckchairs around the cruise ship's pool when the engines need looking at. It's trying to fix what's not broken. It would not contribute one single thing to fixing the many things in CC Mode which need fixing. On the contrary, it would act as a distraction, merely consuming lots more of my time reconciling these changes with the stand-alone CC Mode. In the mean time, there are several reported bugs not being fixed, and the enhancements needed for, e.g., C++11 are not progressing. The time I can spend on Emacs and CC Mode is much less than both of us would like. What needs attending to in CC Mode is NOT its embedding within X?Emacs and it's definitely NOT the lang-var system, which works just fine. It's the complexity in c-guess-basic-syntax, in c-font-lock-declarations, c-forward-type, c-forward-decl-or-cast-1, and many other such functions, and the difficulties this causes. Exasperated, -- Alan Mackenzie (Nuremberg, Germany).