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: 17 Apr 2002 00:34:37 +0200 Sender: emacs-devel-admin@gnu.org Message-ID: <5x662rxog2.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> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1018992971 8172 127.0.0.1 (16 Apr 2002 21:36:11 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 16 Apr 2002 21:36:11 +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 16xacU-00027h-00 for ; Tue, 16 Apr 2002 23:36:10 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 16xaus-0006WY-00 for ; Tue, 16 Apr 2002 23:55:10 +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 16xacR-0004O2-00; Tue, 16 Apr 2002 17:36:07 -0400 Original-Received: from mail.filanet.dk ([195.215.206.179]) by fencepost.gnu.org with smtp (Exim 3.34 #1 (Debian)) id 16xaaO-0004GR-00; Tue, 16 Apr 2002 17:34:00 -0400 Original-Received: from kfs2.cua.dk.cua.dk (unknown [10.1.82.3]) by mail.filanet.dk (Postfix) with SMTP id 952F87C035; Tue, 16 Apr 2002 21:33:47 +0000 (GMT) Original-To: rms@gnu.org In-Reply-To: <200204162018.g3GKI3S24358@aztec.santafe.edu> Original-Lines: 96 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:2676 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:2676 Richard Stallman writes: > SUBMAPS is a list of keymaps which are used at the same > level as the bindings of this keyamp, but comes before those > bindings. > > What does that mean? Consider a keymap K which has a binding for [C-x 1], a keymap P which has a binding for [C-x 2], and a keymap S which has a binding for [C-x 3]. Keymap S has a filter which means that it is only active if mark-active is non-nil. Now, we want keymap P to be a parent map for K, and we want S to be a submap of K. With my proposal, C-x 1, C-x 2, and (if mark-active) C-x 3 will all work seemlessly *without* having to rely on fix_submap_inheritance (which only works for one submap [the parent map] anyway). > What problem is it meant to solve? Multiple keymap inheritance as well as conditional keymaps. > > 3) I understand that there is a problem with evaling code which may > do consing in current_minor_maps, but for most practical > applications I would suppose that this isn't necessary. > > So maybe we can just restrict the FILTER forms/functions to > not being allowed to do consing and document this restriction > in the set-keymap-filter function. > > There is no way to implement such a restriction, > and users don't generally know which functions do consing. This is not intended to be a user feature, it is for package writers. I didn't think we should `implement' the restriction -- simply document it. It could be a fairly short list of `safe' functions to apply to variables, e.g. and, or, not, if, eq, equal, quote, member, memq, get, assoc, car, cdr, aref, =, /=, >, >=, <, <=, symbolp, numberp, vectorp, timerp, (etc) boundp, fboundp, featurep, (etc) I believe this would cover all practical purposes, so I don't see why we need to make a significantly more complex solution to handle some theoritical cases. > > What we should do is make this code work correctly. > If you still think this is what you think is necessary, one solution could be: - memory_full set a global variable 'out-of-memory'. - the command loop will (somehow) determine whether the out-of-memory condition is no longer present e.g. if (out_of_memory) { void *tem = malloc(100000); if (tem) { out_of_memory = 0; free(tem); } } - if out_of_memory is set, the current_maps function will not evaluate the keymap filters, but just assume they evaluate to the most recent result of evaluting the filter. *) I proposed to use a vector [FILTER SUBMAPS PARENT] for the keymap properties. This could easily be extended to store the result of the most recent evaluation of the FILTER, e.g. [FILTER FRES SUBMAPS PARENT] where current_maps would store the result of eval'ing FILTER in FRES. Maybe not a perfect solution, but I believe it would work well enough for this particular purpose (after all, running out of memory fortunately isn't something we experience every day [anymore]). -- Kim F. Storm http://www.cua.dk