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: 20 Apr 2002 00:05:32 +0200 Sender: emacs-devel-admin@gnu.org Message-ID: <5x8z7juyxf.fsf@kfs2.cua.dk> References: <5xbscpg7zl.fsf@kfs2.cua.dk> <200204112243.g3BMhmI01190@rum.cs.yale.edu> <5xd6x5i7ps.fsf@kfs2.cua.dk> <5x4rih12b2.fsf@kfs2.cua.dk> <200204121846.g3CIkZY16909@rum.cs.yale.edu> <5xofgoobzr.fsf@kfs2.cua.dk> <200204122021.g3CKLh217680@rum.cs.yale.edu> <5xu1qd29od.fsf@kfs2.cua.dk> <200204162018.g3GKI3S24358@aztec.santafe.edu> <5x662rxog2.fsf@kfs2.cua.dk> <200204181846.g3IIk2K00596@aztec.santafe.edu> <5xk7r4mwqs.fsf@kfs2.cua.dk> <200204191842.g3JIgnV01056@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 1019250411 18342 127.0.0.1 (19 Apr 2002 21:06:51 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Fri, 19 Apr 2002 21:06:51 +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 16yfal-0004lj-00 for ; Fri, 19 Apr 2002 23:06:51 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 16yfuH-0001l6-00 for ; Fri, 19 Apr 2002 23:27:01 +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 16yfaT-0006Jr-00; Fri, 19 Apr 2002 17:06:33 -0400 Original-Received: from mail.filanet.dk ([195.215.206.179]) by fencepost.gnu.org with smtp (Exim 3.34 #1 (Debian)) id 16yfZ0-0006De-00; Fri, 19 Apr 2002 17:05:02 -0400 Original-Received: from kfs2.cua.dk.cua.dk (unknown [10.1.82.3]) by mail.filanet.dk (Postfix) with SMTP id 137E07C04E; Fri, 19 Apr 2002 21:04:48 +0000 (GMT) Original-To: rms@gnu.org In-Reply-To: <200204191842.g3JIgnV01056@aztec.santafe.edu> Original-Lines: 107 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:2813 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:2813 Richard Stallman writes: > > -- I'm trying to find the > right approach to address the issues with complex modes which uses a > lot of keymaps (like cua and viper) and base the selection between > those keymaps on combining various state information > > Selecting between keymaps is one possible avenue for doing a certain > job. Before we assume it should be done this way, what are the other > avenues? What is the job? Consider C-x. Normally, it works as a prefix key for things like C-x C-f etc. Basically, with cua, if the mark is active, hitting C-x starts a 0.2 seconds timer. If the timer runs out, C-x works like C-w (kill-ring-save). If the user enters another C-x within those 0.2 seconds, the first C-x is ignored and the second C-x works like a normal prefix key. Also if the user enters another key, e.g. C-f, within those 0.2 seconds, the first C-x now works like a prefix key, i.e. as C-x C-f. [all of this was discussed a year ago as ways to let the user circumvent cua's C-x handling]. The actual interpretation of C-x is done via three of cua's 7 keymaps. To complicate things, cua also supports rectangles and a global mark, which all work using the same command set as is used for the region, e.g. you also use C-x (or C-w) to kill the rectangle (and C-y to insert it), or if the global mark is set, C-x will move the selected region or rectangle to the global mark position... To facilitate this, three more keymaps are used which selectively does command remapping of `kill-ring-save' to handle either region, rectangle, or the global mark. The final keymap is used to allow users to take advantage of cua's uniform command set for rectangles (and the global mark), but still continue to use C-w, M-w and C-y instead of C-x, C-c, and C-v (which are the normal cua bindings). Having gone through a major overhaul of the cua code, I can definitely say that basing this on multiple minor-mode keymaps is a major improvement. The primary advantage is that code is much simpler to maintain now. > > I have N keymaps which all make bindings starting with C-x -- and I want > all of those bindings to "work". > > What job are these bindings supposed to *do*? Given time I could > figure that out from the code you sent, but I don't have that time. > Ok, but considering that I've spent more than 200 hours on this project maybe you could give my views some weight -- I have tried various alternatives to the current approach, and it is by far the best approach so far!! > If it wasn't for the problem evalling code in the current_minor_maps > function [I believe there are ways to solve that], would that solution > be acceptable? > > Not necessarily. It would still be a big extension in an area where > the code is already too complex. Multiple inheritance is inherently a > mess. Once it was added, it would probably require subsequent work to > fix bugs or to add more features so people can "fully use" it. The emulation-mode-map-alist and conditioned keymaps doesn't add multiple inheritance (that was part of my other proposal, once the emulation-mode-map-alist idea was rejected). It is primarily a way for packages like cua to be able to configure its (multiple) keymaps once and for all without worrying about other packages messing them up. I don't see why this is a significant complication. And what ever errors is potentially associated with it, I feel confident I can fix. > > > Multiple inheritance is a mess. We should avoid it if we can. > > But the `parent keymap' inheritance is already pretty messy. > > That is why we should not make it any hairier. > > Please don't use arguments of the form "We already have this kind of > problem, therefore it it doesn't matter if we add to it." That is the > wrong approach for any serious problem, and I can promise you I will > say no. > Ok, since this wasn't really an issue with my initial proposal (the emulation-mode-map-alist), I will leave it to Stefan to defend any changes added for the purpose of multiple inheritance. Please do not confuse my requirements for cua with multiple inheritance issues. -- Kim F. Storm http://www.cua.dk