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: Further CC-mode changes Date: Fri, 12 Sep 2014 23:04:26 -0400 Message-ID: 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> <20140912235948.GA4045@acm.acm> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1410577496 8988 80.91.229.3 (13 Sep 2014 03:04:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 13 Sep 2014 03:04:56 +0000 (UTC) Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Sep 13 05:04:49 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 1XSddn-0007s5-5o for ged-emacs-devel@m.gmane.org; Sat, 13 Sep 2014 05:04:47 +0200 Original-Received: from localhost ([::1]:48094 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XSddm-0006Mx-Pw for ged-emacs-devel@m.gmane.org; Fri, 12 Sep 2014 23:04:46 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58389) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XSddc-0006A9-C4 for emacs-devel@gnu.org; Fri, 12 Sep 2014 23:04:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XSddU-0005ht-Qq for emacs-devel@gnu.org; Fri, 12 Sep 2014 23:04:36 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:34140) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XSddU-0005hp-Lf for emacs-devel@gnu.org; Fri, 12 Sep 2014 23:04:28 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUGAIDvNVNFpZEG/2dsb2JhbABZgwaDSsA9gRcXdIIlAQEBAQIBViMFCwsOJhIUGA0kiAQI0hkXjhgRAVAHhDgEk0GVWIFqg0whgTU X-IPAS-Result: ArUGAIDvNVNFpZEG/2dsb2JhbABZgwaDSsA9gRcXdIIlAQEBAQIBViMFCwsOJhIUGA0kiAQI0hkXjhgRAVAHhDgEk0GVWIFqg0whgTU X-IronPort-AV: E=Sophos;i="4.97,753,1389762000"; d="scan'208";a="89573562" Original-Received: from 69-165-145-6.dsl.teksavvy.com (HELO ceviche.home) ([69.165.145.6]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Sep 2014 23:04:26 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 779E5660D3; Fri, 12 Sep 2014 23:04:26 -0400 (EDT) In-Reply-To: <20140912235948.GA4045@acm.acm> (Alan Mackenzie's message of "Fri, 12 Sep 2014 23:59:48 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.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.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:174261 Archived-At: >> - 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. I think "more general" is a disadvantage in this case (I'd rather not have auto-indentation after I paste a space). As for better supported, I don't care too much: I'd just keep the old abbrev code for the Emacsen that don't have post-self-insert-hook yet. >> 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"?? The patch. >> - 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, Such as? > and break uniformity between the modes. Actually, I think the right move would be to move all awk-related code into cc-awk.el, thus making it more uniform with the various externally maintained cc-modes. > This change wouldn't enhance functionality or maintainability. The code is cleaner and simpler with the change than without. >> - make awk-mode use syntax-propertize when available. > Why? You know why: `syntax-propertize' is used by all major modes except cc-mode derived ones. And it's more efficient, because it's more lazy. Also its correctness argument is much simpler since it doesn't rely on interactions between before-change-functions, after-change-functions (and font-lock), contrary to your code. > It's a lot of work to change, It's work I did, pro bono. Just enjoy it. > 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. Indeed it's not. If you want to be sure that syntax properties have been applied upto POS, you need to call (syntax-propertize POS). > This change wouldn't enhance functionality or maintainability. Yes, it enhances maintainability of awk-mode by making it work more like all other modes. It also stops cc-mode from doing all kinds of weird unrelated crap having to do with maintaining c-found-types and c-state-cache, which are not used in cc-awk. >> - Use define-derived-mode's built-in keymap inheritance rather than >> c-make-inherited-keymap. > c-make-inherited-keymap is simpler. Huh? Have you even looked at the patch? There is nothing to do to use define-derived-mode's built-in keymap inheritance, so how can your extra code be simpler? > This change wouldn't enhance functionality or maintainability. It removes unneeded code. That improves 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. It just makes code more standard, with no known downside. >> - 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? The current code of c-after-font-lock-init has a bug, but no the current cc-mode does not trigger this bug. The bug is that c-after-font-lock-init is supposed to *move* c-after-change to the front of after-change-functions, but in case c-after-change is not in after-change-functions, it ends up *adding* it instead. Your approach to syntax-table properties requires you to be extra careful about ordering between c-after-change and font-lock's own after-change-functions, hence the c-after-font-lock-inithack. But if for some reason some cc-mode (such as cc-awk when it uses syntax-propertize) does not need/want c-after-change, the current code in c-after-font-lock-init will end up making it needlessly difficult to remove c-after-change from after-change-functions. >> - 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. That's why I also do it from hack-local-variables-hook. > How about enhancing define-derived-mode so that modes that have things > to do after running their hooks can do them? That's not late enough, since you need to do it after setting the file-local variables. In this particular case, the better fix would be to introduce a new `mode-name-sidekick' in the mode-line-format, so we can get rid of c-update-modeline altogether. >> - 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? Why not? > 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. What complexity? It reduces code duplication, if anything. > In that patch, your assumptions about what AWK Mode needs in > c-{before,after}-change were incorrect. Could you help me understand what I missed? > 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. I admit to not remembering, especially not the remaining bug due to using prog-mode. Can you remind us which bug this is? > 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. Any package always has several problems that need fixing. Just because a change doesn't fix what you see as the main problem doesn't mean it should be rejected. My overall aim is to make cc-modes more "standard" so as to lower the entry barrier for other people. I also want to make it more modular, which I thought I'd start by moving all the awk functionality out of the generic part of the code and into cc-awk. > It's trying to fix what's not broken. I'm not sure what other people on this list feel like w.r.t cc-mode, but personally so far my attitude has been to close my eyes and pinch my nose while forwarding the bugs to you because the code is so horrendously outlandish, messy, and outdated. > 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. The problem here is not my changes, it's having those two separate code bases. There is no good reason to have 2 different code bases. So let's fix this problem once and for all by merging the two and then make sure they can't diverge any more (i.e. by using the Emacs code as the place where development happens). > 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. On the one hand you say that you don't have enough time to deal with CC-mode, and on the other you reject the rare patches sent your way. If you prefer that I keep just forwarding bug-reports to you and never ever again look at cc-mode, I can do that. But if you want help, you'll need to be a bit more flexible. > 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. One thing at a time. Stefan