From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: storm@cua.dk (Kim F. Storm) Newsgroups: gmane.emacs.devel Subject: Re: Enhancements to "minor-mode-map-alist" functionality. Date: 14 Apr 2002 01:30:50 +0200 Sender: emacs-devel-admin@gnu.org Message-ID: <5xbscnb2hh.fsf@kfs2.cua.dk> References: <5xbscpg7zl.fsf@kfs2.cua.dk> <200204131905.g3DJ5cC22812@aztec.santafe.edu> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1018737214 5175 127.0.0.1 (13 Apr 2002 22:33:34 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sat, 13 Apr 2002 22:33:34 +0000 (UTC) Cc: emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 16wW5O-0001LM-00 for ; Sun, 14 Apr 2002 00:33:34 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 16wWML-00025o-00 for ; Sun, 14 Apr 2002 00:51:05 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16wW55-0001Sx-00; Sat, 13 Apr 2002 18:33:15 -0400 Original-Received: from mail.filanet.dk ([195.215.206.179]) by fencepost.gnu.org with smtp (Exim 3.34 #1 (Debian)) id 16wW1y-0008Al-00; Sat, 13 Apr 2002 18:30:02 -0400 Original-Received: from kfs2.cua.dk.cua.dk (unknown [10.1.82.3]) by mail.filanet.dk (Postfix) with SMTP id D1CF07C035; Sat, 13 Apr 2002 22:29:59 +0000 (GMT) Original-To: rms@gnu.org In-Reply-To: <200204131905.g3DJ5cC22812@aztec.santafe.edu> Original-Lines: 59 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2.50 Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.9 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:2619 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:2619 Richard Stallman writes: > - the new cua need a total of 7 minor mode keymaps, which must be > processed in a specific order, and before all other minor mode > keymaps > > I am surprised that the present facilities can't be used more easily. > Could you explain WHY you think this is necessary? Perhaps there > is already a better way. I'm pretty confiden that there isn't a _better_ way already. There are various ways to do this with the current facilities, but none of them are really satisfactory (take a look at viper mode's frequent checking of the minor-mode-map-alist to see what I mean). I'm trying to come up with a way to transparently enhance emacs' ability to "change personality" in a way that can be configured more statically. > > 2) Allow selection of the active keymaps in the alist to > be based on evaluating a form in addition to a simple variable. > > Any extension to the keymap mechanism calls for careful thought. > Please don't rush ahead to install any changes there before we > have time to discuss this. Sure! I did expect some feedback on this, and although my changes looks fairly simple, I've already been convinced that my approach isn't sufficiently generic. > > First let's see if change is really needed. If so, then let's > understand what the problem is. I've tried to explain this several times already... The fundamental problem is that some modes (like viper and cua) makes some quite fundamental changes to the way some of the standard keys works [cua remaps C-c and C-x depending on the current state of the mark (and other conditions), while viper operates in command or insert mode]. Although the current facilities are sufficient (99% at least), they _definitely_ are neither elegant, nor efficient, so I would like emacs to provide some kind of standard feature to better support such modes. E.g. for cua, I need to ensure that those 7 keymaps are in the front of minor-mode-map-alist after every command, and I need to set 7 different variables based on the current state so that the next command can be interpreted correctly... and then I have to be careful to modify that state if a timer is run which changes the state [which isn't always possible in theory, although I haven't seen the problem in practice.] I'm thinking about other ways to do this... -- Kim F. Storm http://www.cua.dk