From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Emacs learning curve Date: Sun, 18 Jul 2010 22:00:38 +0900 Message-ID: <87oce5ymfd.fsf@uwakimon.sk.tsukuba.ac.jp> 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> <87oce6cdas.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 1279457957 30829 80.91.229.12 (18 Jul 2010 12:59:17 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 18 Jul 2010 12:59:17 +0000 (UTC) Cc: "Uday S. Reddy" , emacs-devel@gnu.org To: Teemu Likonen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jul 18 14:59:16 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 1OaTSa-0001Pv-1M for ged-emacs-devel@m.gmane.org; Sun, 18 Jul 2010 14:59:13 +0200 Original-Received: from localhost ([127.0.0.1]:48505 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OaTSX-0001zr-76 for ged-emacs-devel@m.gmane.org; Sun, 18 Jul 2010 08:59:09 -0400 Original-Received: from [140.186.70.92] (port=35472 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OaTSQ-0001zm-GU for emacs-devel@gnu.org; Sun, 18 Jul 2010 08:59:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OaTSP-00010S-09 for emacs-devel@gnu.org; Sun, 18 Jul 2010 08:59:02 -0400 Original-Received: from mtps02.sk.tsukuba.ac.jp ([130.158.97.224]:50908) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OaTSO-00010C-Gi for emacs-devel@gnu.org; Sun, 18 Jul 2010 08:59:00 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mtps02.sk.tsukuba.ac.jp (Postfix) with ESMTP id 856CA820F; Sun, 18 Jul 2010 21:58:59 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 46B9B1A26B9; Sun, 18 Jul 2010 22:00:38 +0900 (JST) In-Reply-To: <87oce6cdas.fsf@mithlond.arda> X-Mailer: VM 8.0.12-devo-585 under 21.5 (beta29) "garbanzo" ed3b274cc037 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) 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:127551 Archived-At: Teemu Likonen writes: > * 2010-07-17 15:28 (+0100), Uday S. Reddy wrote: > > In a supposedly configurable editor, it is pretty hard to change key > > bindings. It's trivial to change key bindings. M-x local-set-key RET RET and Bob's your uncle. Or maybe you want a swap-keys command that would have the UI M-x swap-keys RET . I don't have that function on the top of my head, but I'm pretty sure it requires at most three lines to express. What's hard to do is to do this in a way that maintains any consistency. That is the difference between Emacs and your average editor designed for the below-average user: Emacs has a lot more commands and real users with any amount of experience (often as little as two or three months!) use enough of those bindings that they feel pain upon remapping. Of course many of the Emacs bindings are pretty arbitrary (eg, P-N-U-D for previous-next-up-down would do just as well as B-F-P-N for backward-forward-previous-next). However, you need to fix all of the related bindings for the different movement units. > 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)? No. I think you'll find that it's not used as frequently as you think. Many commands that *should* do slightly different things in different modes already *do* do those things in the different modes, by virtue of hooks in the commands. If you rebind the command to a different key, all the mode-dependent behavior goes with it. I just don't think this is the root of the problem. And even if it is, I think the right way to handle it is to make the command itself configurable. The problem is when modes bind completely different functions to the keys. If you decide to rearrange the mappings of core commands, users of such mode will lose. The mode programmer often has a rationale for the key bindings chosen, such as mnemonic initials.