Re: Alternative design for keymap code

[Sven Wischnowsky <wischnow@informatik.hu-berlin.de>]

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