Hi Stephane,

It sounds like we did something similar. The KeyMapper adds an iv to 
TextMorph called keyMapper, and each keymapper can have it's own 
keymappings. If a keysequence is matched, it's "target" is called with 
the desired command selector. If the selector takes an argument, then 
the entire key sequence is passed as the argument to the selector.

A little bonus is a facility for creating commands that "type" a 
sequence of keystrokes. For instance, if you mapped a keysequence to the 
command #myNewCommand, then added a method #myNewCommand (to the target) 
that does this:
	self playKMKeystrokes: '<m-cr><tab>ifTrue:[]<left>'
Then if you triggered the command, "ifTrue:[]" would be typed on the 
next line, indented, with the cursor winding up between the brackets. 
(<m-cr> is KeyMapper-ese for alt-enter, <left> is the left arrow key).

I included a few sample custom commands in the changeset.

Below is the KeyMapper class comment if your interested:

===== from KeyMapper class comment =====
Provides the ability to bind multi-key sequences to commands. As of this 
writing only implemented for TextMorph.

Syntax for keybindings is below. Also see the examples in 'default 
bindings'.

Inst variables:
	keymap -
		A dict of key mappings
	sorted -
		A sorted collection of key sequences
	target -
		The object that is notified by keymapper (details below)
	buffer -
		Contains the key events typed so far during the current key match attempt.

The target must implement a few methods:

keyMapperCommandInProcess:
Called to alert the target that the user has partialy matched, but  not 
completely matched, a registered key sequence. The intent of this 
callback is to allow targets to modify the cursor or provide some other 
visual cue that a multi-key command is being entered.

keyMapperFinishedCommand:
Called to alert the target that a command has been matched. The intent 
of this callback is to allow targets to remove any visual feedback given 
to the user to indicate a command is being entered.

keyMapperNoMatch:
Called to alert the target that a command has been aborted (user  typed 
an invalid key sequence that partialy matched a registered command. The 
intent of this callback is to allow targets to  remove any visual 
feedback given to the user to indicate a  command is being entered.

================

Keybindings Syntax (also see examples in default bindings)

A "keybinding spec" must be passed to KeyMapper during instance 
creation. It should have the following form:

	{ assoc1. assoc2. assoc3...assosN }

Each assoc should have the folowing form:

	'keyString'->#myCommand

The value of assoc (#myCommand in the above example) is a method that 
will be called on the 'target' when a key sequence has been matched. The 
handler should take 0 or 1 arg. If it takes 1 arg, then the entire key 
sequence is passed to the handler method in the form of a collection of 
KeyboardEvents.

The 'keyString' is the sequence of keystrokes to be matched. The syntax 
for describing keystrokes is below.

	
============
KeyString Syntax

Special keys like home, ins, etc. are represented as follows:
	<home> <end> <ins> <bs> <tab> <pgup> <pgdn> <cr> <esc>
	<left> <right> <up> <down> <space> <del>
	<space><tab>
Note: Use <space> and <tab> when creating KMFakeKeyEvent for those 
characters (as opposed to $ and $	).

Keys modified by the control key are represented as follows:
	<c-x> (matches control-x)
	<c-X> (matches control-X, ie. capital X)
Keys modified by the meta key (alt or comand key) are represented as 
follows:
	<m-x> (matches meta-x)
	<m-X> (matches meta-X)

Keys that are not modified by the control or meta key are represented 
normally in a keystring. For instance: 'abc'

Another Example:
If the line below were included in a keymapper spec, then KeyMapper 
would execute the method #doSomething on the target when the user types 
control-a, then meta-b, then A (capital a), then b, and finally c"
	'<c-a><m-b>Abc'->#doSomething.

=======
Keys That Can't Be Mapped

The ability to specify the 'shift' key is not included at this time.
See the class coment of KMFakeKeyEvent for a detailed list of events 
that cannot be mapped.

========================================


Stephane Ducasse wrote:
> Hi Steven
> 
> I was about to bring from the graveyard my implementation to get 
> paragraphEditor
> handling multiple key binding table. So that on a per-instance based we 
> could have different bindings.
> 
> Do you think that this is worth? or should I use your Keymapper?
> I would really to have that kind of simple functionality in the image. 
> Is keymapper fixing paragraph editor? Because my changes were small 
> (introducing the right instance and class var in paragraph editor, 
> fixing all the methods to use the instance var) and adding a Binding class.
> 
> Stef