From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Keymap initialization Date: Mon, 26 Jun 2017 16:27:04 -0400 Message-ID: References: <20170615210438.18512.16715@vcs0.savannah.gnu.org> <20170615210440.2D57C206CD@vcs0.savannah.gnu.org> <20170626163957.GB2471@acm> <20170626180807.GC2471@acm> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1498508890 14671 195.159.176.226 (26 Jun 2017 20:28:10 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 26 Jun 2017 20:28:10 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 26 22:28:06 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dPac4-0003NH-9T for ged-emacs-devel@m.gmane.org; Mon, 26 Jun 2017 22:28:00 +0200 Original-Received: from localhost ([::1]:48390 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dPac9-0002W6-Ib for ged-emacs-devel@m.gmane.org; Mon, 26 Jun 2017 16:28:05 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54114) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dPab4-0001I0-WE for emacs-devel@gnu.org; Mon, 26 Jun 2017 16:27:00 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dPaax-0001IC-VY for emacs-devel@gnu.org; Mon, 26 Jun 2017 16:26:58 -0400 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:58136) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dPaax-0001Hv-No for emacs-devel@gnu.org; Mon, 26 Jun 2017 16:26:51 -0400 Original-Received: from lechazo.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id v5QKQok7023085; Mon, 26 Jun 2017 16:26:50 -0400 Original-Received: by lechazo.home (Postfix, from userid 20848) id E6109601A3; Mon, 26 Jun 2017 16:27:04 -0400 (EDT) In-Reply-To: <20170626180807.GC2471@acm> (Alan Mackenzie's message of "Mon, 26 Jun 2017 18:08:07 +0000") X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 2 Rules triggered EDT_SA_DN_PASS=0, RV6056=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6056> : inlines <5951> : streams <1751636> : uri <2451337> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.20 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:216014 Archived-At: >> C-M-x on the (defvar foo-map ...) takes care of it as well. Or using >> `defconst` instead of `defvar` would do the trick also (although that's >> also less idiomatic). Or write a new M-x reload-file which causes all >> the defvars to be re-evaluated. > Workarounds, every one. Like your solution. As I said, they all have advantages and disadvantages. E.g. your solution will override some ~/.emacs changes to the cc-mode map when reloading the file. And it will fail to remove old bindings when you change your code (e.g. when you move a binding from one key to another or when you remove a binding altogether). It has various other additional failure modes. > Why do you think things should be standardised? (Not a rhetorical > question) It's important for the core Emacs maintainers so they can fix things without having to decypher all the idiosyncrasies of all packages. It's important for the end user who uses various major modes (which I'd expect to be a large fraction of Emacs users) and will benefit from fewer surprises due to gratuitous subtle differences between the different major modes. Also, standardization is generally a necessary first step before being able to consolidate. Consolidation in turn means that all major modes will get more features out of the box with less work on the coder's part. What benefit do you see in CC-mode being non-standard? >> IOW, rather than make CC-mode yet-a-bit-more different from the rest of >> Emacs, I wish you would try to find a way to solve your problem globally. >> If this annoyance affects you, there's a good chance it affects many >> other developers, so finding a general solution would be a lot better. > That seems to presume that the way things are already done in Emacs is > at or near some optimum, and deviating from that way is therefore > sub-optimal. Actually, if you read carefully, nowhere did I say that the current idiomatic way is in itself better. I'm OK with changing the standard to fix problems with it. What I object to is having a single package (e.g. CC-mode) stray from the currently followed standard for reasons unrelated to the specificities of this package. IOW I would object less strenuously to a patch which applies the same change to all of Emacs's major modes. > I don't think there's any evidence for this. I see some "standard" > ways of doing things in Emacs which I don't think are good. I often see that as well. My reaction is to try and change that in a way which works for everyone. Your reaction instead seems to be "oh screw them, I'll do it my way". > Setting key map entries at load time could be a general solution to that > particular annoyance. People, having seen it in CC Mode, will be able > to adapt it for their own modes, should they see fit. That could be an OK argument in theory, but this approach has been used for many years in many packages and did not prove superior (nor significantly worse, indeed). Stefan