From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6427 invoked from network); 2 Jul 1999 06:57:00 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 2 Jul 1999 06:57:00 -0000 Received: (qmail 22173 invoked by alias); 2 Jul 1999 06:56:36 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 6942 Received: (qmail 22166 invoked from network); 2 Jul 1999 06:56:36 -0000 Date: Fri, 2 Jul 1999 08:56:35 +0200 (MET DST) Message-Id: <199907020656.IAA15483@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: "Anthony J Heading"'s message of Thu, 1 Jul 1999 22:14:56 +0800 Subject: Re: Alternative design for keymap code Anthony J Heading wrote: > The current keymap code isn't optimally structured for that, and indeed > struck me as a little simplistic - the only relationships on keymaps are > deep copying and aliasing. And the structure of a fixed 256 key array for > single keystrokes and a hash table for multistroke commands seemed an ugly > optimisation. Agreed. Wholeheartedly. Btw, I just wanted to keep the code-change as small as possible when I wrote those local keymaps we currently have. And was planning to come back to it later... I also never understood why we have this aliasing thing instead of a bindkey-option that just sets the keymap to use. If I remember correctly I wasn't here when this (or at least parts of it) were implemented, so I missed the discussion. Hm, time to read the archive, I guess. > I replaced the keymap lookup code with an optimised hash table - basically > something I learnt from perl 5.000alpha6, but which also keeps the chains > ordered by key sequence length. Using a hash function h <- 33 * h + > newchar means that by setting the hash table width to 256 the single > keystrokes would be distributed one-per-bucket and always be the first > element. Which is good for speed (if one thought that one could type > faster than a CPU could read). So no need for the fixed array, but also > no need for the width to be 256 if one wanted a small overlay map. This sounds good, too. > I then also implemented a distinction between unbound keys and keys bound > to undefined-key. Finding the latter in a keymap means the key really > does nothing, while the former case is 'transparent' - the search simply > fall through to the next underlying keymap. When a final definition (or > lack thereof) is found, it's cached in the top level map. Again good > efficiency wise. Yes, I like this, too. (Making undefined-key the hole in local keymaps as it currently is is ugly.) > After reflecting for a while, I believe there's still value in some of the > design. And I'm thinking instead that maybe there should be a shell > parameter KEYMAP/keymap pair, which specificies the prevailing set of > keymaps. These are searched in order. Shell function are then able to > push their own map onto the head the list if they need. And by allowing > the KEYMAP parameter to be function-local, exit cleanup is automatic. And this sounds good to me, too. So, I'd vote for cleaning up the keymap structure and selection mechanism a bit and to give users a simple way to modify the keymaps to use (either with a special array or via bindkey-option). Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de