Too bad. The only response I received which concerns `keymap.c' (not `viper' package) is requesting to repeat what is just stated (as a message reference) in the original message. It concerns bug described in <00b33c26373771-gin(a)mo.msk.ru&gt; posted to <xemacs-beta(a)xemacs.org&gt; on Sun, 23 Dec 2001 19:57:44 (GMT). See above. No. I (1) updated `viper' package; and (2) stopped using packages using extent keymaps (in particular, `wid-edit' editing functions). I am repeating the original bug descrition here. `key-binding' misinforms user when used by `describe-key' invoked inside an extent on a key from keymap of that extent. That is, pressing key invokes a function from the extent keymap, but `describe-key' of the same key describes another function from another keymap. It occurs regularly with extents created as `wid-edit' "text fields". It happens because `get_relevant_keymaps' <- `key-binding' does not traverse extent keymaps when `keys' arg of `key-binding' is a string, not a vector of events. `key-binding' `keys' arg is copied from `describe-key' `key' which should be vector of events, as `interactive' function description says. But when `viper' versions prior to 1.33 is loaded, it calls `defadvice describe-key ...' so that `keys' arg may become a string (which also describes a sequence of keys). There is no reason not to process such an arg reasonably, but `get_relevant_keymaps' has to be changed to do this. `viper' since 1.33 does not call `viper-events-to-keys' in `describe-key' advice, so `keys' arg never becomes a string, and updating viper fixes the bug for me; thanks to Michael Kifer.