From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Per Abrahamsen Newsgroups: gmane.emacs.devel Subject: Re: Customizing key bindings (was: Re: [CVS] f7, f8 bound..) Date: Sat, 07 Sep 2002 15:07:07 +0200 Organization: The Church of Emacs Sender: emacs-devel-admin@gnu.org Message-ID: References: <87ofbji88u.fsf@emacswiki.org> <87sn0scb0b.fsf@emacswiki.org> <200209061728.g86HSVp32767@rum.cs.yale.edu> <20020906220339.GA7270@gnu.org> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1031404150 11749 127.0.0.1 (7 Sep 2002 13:09:10 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sat, 7 Sep 2002 13:09:10 +0000 (UTC) Cc: Stefan Monnier , rms@gnu.org, emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 17nfKm-00033M-00 for ; Sat, 07 Sep 2002 15:09:08 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17nftk-0000GW-00 for ; Sat, 07 Sep 2002 15:45:17 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 17nfKj-00051j-00; Sat, 07 Sep 2002 09:09:05 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17nfJ0-0004rX-00 for emacs-devel@gnu.org; Sat, 07 Sep 2002 09:07:18 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17nfIy-0004pr-00 for emacs-devel@gnu.org; Sat, 07 Sep 2002 09:07:18 -0400 Original-Received: from sheridan.dina.kvl.dk ([130.225.40.227]) by monty-python.gnu.org with esmtp (Exim 4.10) id 17nfIv-0004mm-00; Sat, 07 Sep 2002 09:07:13 -0400 Original-Received: from zuse.dina.kvl.dk (zuse.dina.kvl.dk [130.225.40.245]) by sheridan.dina.kvl.dk (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id PAA01114; Sat, 7 Sep 2002 15:07:10 +0200 Original-Received: (from abraham@localhost) by zuse.dina.kvl.dk (8.9.3+Sun/8.9.3) id PAA29125; Sat, 7 Sep 2002 15:07:07 +0200 (MEST) X-Authentication-Warning: zuse.dina.kvl.dk: abraham set sender to abraham@dina.kvl.dk using -f Original-To: Miles Bader X-Face: +kRV2]2q}lixHkE{U)mY#+6]{AH=yN~S9@IFiOa@X6?GM|8MBp/ In-Reply-To: (Per Abrahamsen's message of "Sat, 07 Sep 2002 14:01:30 +0200") Original-Lines: 44 User-Agent: Gnus/5.090007 (Oort Gnus v0.07) Emacs/21.1 (sparc-sun-solaris2.8) Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:7686 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:7686 Per Abrahamsen writes: > Miles Bader writes: > >> On Fri, Sep 06, 2002 at 01:28:30PM -0400, Stefan Monnier wrote: >>> > M-x customize-option global-key-bindings >>> >>> I must say I really dislike the idea of customizing >>> `global-key-bindings' when I actually want to change `global-map'. >> >> Agreed. Customize should be a friendly face for the existing infrastructure, >> not a distant relative... > > Emacs will never be easy to customize, then. Maybe I should elaborate... The problem isn't global-key-bindings, it can easily be named "global-map" with no loss of functionality. The problem is the mindset that making complex applications written by programmers for programmers easy to configure, is simply a matter of providing a "friendly" interface to the existing configuration mechanisms. This mindset is shared by most traditional Unix developers (and probably Lisp developers too, but who cares). However, this assumes that being "easy to configure" is merely a matter of "syntactical sugar", that is, provide a form based interface to the old text based configuration files. What it really does is to force users to think like programmers, which of course is a lot easier to the programmer than having programmers think like users. Note: Here I use "user" to mean the kind of end-users who would never become programmers, or edit a configuration file directly. I know programmers are users too, and even can benefit a form based customization interface, but they are not the kind of users who really *need* such an interface, If you want to make configuration easy to the end-users, you need to start with their needs, and not with the old textual configuration files. It is one area where MS Windows and Mac programmers tend to be better than Unix programmers.