From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Keymap initialization Date: Mon, 26 Jun 2017 21:13:33 +0000 Message-ID: <20170626211333.GF2471@acm> 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; charset=us-ascii X-Trace: blaine.gmane.org 1498511703 15492 195.159.176.226 (26 Jun 2017 21:15:03 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 26 Jun 2017 21:15:03 +0000 (UTC) User-Agent: Mutt/1.7.2 (2016-11-26) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 26 23:14:57 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 1dPbLO-0003Mr-VB for ged-emacs-devel@m.gmane.org; Mon, 26 Jun 2017 23:14:51 +0200 Original-Received: from localhost ([::1]:48589 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dPbLU-00057x-0z for ged-emacs-devel@m.gmane.org; Mon, 26 Jun 2017 17:14:56 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39932) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dPbLK-00056l-OP for emacs-devel@gnu.org; Mon, 26 Jun 2017 17:14:47 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dPbLH-0002H5-Eg for emacs-devel@gnu.org; Mon, 26 Jun 2017 17:14:46 -0400 Original-Received: from ocolin.muc.de ([193.149.48.4]:31567 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1dPbLH-0002FX-3i for emacs-devel@gnu.org; Mon, 26 Jun 2017 17:14:43 -0400 Original-Received: (qmail 38270 invoked by uid 3782); 26 Jun 2017 21:14:41 -0000 Original-Received: from acm.muc.de (p548C6649.dip0.t-ipconnect.de [84.140.102.73]) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 26 Jun 2017 23:14:40 +0200 Original-Received: (qmail 5539 invoked by uid 1000); 26 Jun 2017 21:13:33 -0000 Content-Disposition: inline In-Reply-To: X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x [fuzzy] X-Received-From: 193.149.48.4 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:216017 Archived-At: Hello, Stefan. On Mon, Jun 26, 2017 at 16:27:04 -0400, Stefan Monnier wrote: > 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. Only CC Mode developers are likely to be reloading the file. It would be nice to be able to remove the old bindings, but that's hardly as important as getting the new ones loaded. > > 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? It can actually be written and maintained. CC Mode probably rates amongst the top few packages in terms of difficulty, and that difficulty is mainly due to the topic of the mode (particularly the more recent versions of C++), though unfortunate maintenance choices over the decades have certainly contributed to it. Constraining it to "standard" ways of working would make it too complicated to be maintained. > >> 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. Such patches are beyond my capacity to make, certainly if I want to carry on with CC Mode, too. > > 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". There are a few improvements I've tried to make in the Emacs core, only to get knocked back. I'm more wary about spending time there, now. I also value KISS. Some of the things you seem to want in CC Mode would complexify it. > > 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). Given how little difficulty either approach will cause in practice, there seems to be little to speak for a rigid common approach. We have, perhaps, both been wasting time over the past few hours discussing it. > Stefan -- Alan Mackenzie (Nuremberg, Germany).