From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Teemu Likonen Newsgroups: gmane.emacs.devel Subject: Re: Emacs learning curve Date: Sat, 17 Jul 2010 18:56:27 +0300 Message-ID: <87oce6cdas.fsf@mithlond.arda> References: <4C3B6A8A.80105@gmx.de> <87iq4f8gyh.fsf@telefonica.net> <874ofzl2ji.fsf@mithlond.arda> <201007162023.32116.tassilo@member.fsf.org> <87zkxrjihf.fsf@mithlond.arda> <8739vjf2k2.fsf@gmail.com> <8739vi8x39.fsf@mithlond.arda> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1279382243 17390 80.91.229.12 (17 Jul 2010 15:57:23 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 17 Jul 2010 15:57:23 +0000 (UTC) Cc: emacs-devel@gnu.org To: "Uday S. Reddy" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jul 17 17:57:21 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Oa9lO-0002Dw-L4 for ged-emacs-devel@m.gmane.org; Sat, 17 Jul 2010 17:57:18 +0200 Original-Received: from localhost ([127.0.0.1]:37917 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Oa9lO-0008JJ-5y for ged-emacs-devel@m.gmane.org; Sat, 17 Jul 2010 11:57:18 -0400 Original-Received: from [140.186.70.92] (port=48521 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Oa9lH-0008JD-MC for emacs-devel@gnu.org; Sat, 17 Jul 2010 11:57:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Oa9lG-0005bp-6l for emacs-devel@gnu.org; Sat, 17 Jul 2010 11:57:11 -0400 Original-Received: from mta-out.inet.fi ([195.156.147.13]:54238 helo=kirsi1.inet.fi) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Oa9lF-0005bK-Sz for emacs-devel@gnu.org; Sat, 17 Jul 2010 11:57:10 -0400 Original-Received: from mithlond.arda (84.251.132.215) by kirsi1.inet.fi (8.5.122) id 4C2999BC00A2D88B; Sat, 17 Jul 2010 18:57:03 +0300 Original-Received: from dtw by mithlond.arda with local (Exim 4.69) (envelope-from ) id 1Oa9kZ-0005eo-Vl; Sat, 17 Jul 2010 18:56:27 +0300 In-Reply-To: (Uday S. Reddy's message of "Sat, 17 Jul 2010 15:28:19 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:127520 Archived-At: * 2010-07-17 15:28 (+0100), Uday S. Reddy wrote: > On 7/17/2010 7:02 AM, Teemu Likonen wrote: >> Anyway, I'm not trying to change anybody's mind about the default key >> bindings. I have just been hoping that user could practically design >> her own global bindings but even that's not quite possible because >> the f-b-n-p mnemonics and other default keys are so deeply hard-coded >> everywhere. There's not enough abstraction on that front. > > I think you are right. I was thinking the same thing this morning. > > In a supposedly configurable editor, it is pretty hard to change key > bindings. This seems like a deep flaw in the architecture of Emacs. > Perhaps this is what the emacs developers should focus on: make the > key bindings configurable. Then there would be no need to go through > debates like this any more. And to not sound too much like "Emacs developers should do this" I can do some of the work myself. In my opinion the cleanest way to create and experiment with different global key bindings is to create global minor modes. Such modes are clearly separate units from other parts of emacs and can be published in places like the Emacs wiki. Currently the global minor mode approach doesn't work very well because - modes use function substitute-key-definition which refer to the global-map directly. Key bindings in global minor modes won't be substituted. - modes overwrite global keys by hard-coding keys to commands. If those both are changed to _command_ remapping, such as (define-key MAP [remap next-line] 'modes-custom-next-line) then the minor mode approach would work and we would be quite far already. But do we agree that using substitute-key-definition with reference to global-map is bad and should be replaced with command remapping (see above)?