key bindings reported incorrectly

key bindings reported incorrectly

[Ilya N. Golubev]

Versions: 20.7, 21.4a

Environment: viper enabled.

In help buffer formed by `f1 b', when viper vi movement mode is in
effect, `f1 k N' reports:

N runs the command viper-search-Next
   which is an interactive compiled Lisp function in `viper-cmd'.
(viper-search-Next ARG)

So does `f1 b' report.

Actually `N' does nothing in that buffer.  `/' was already invoked.
In this case `viper-search-Next', if ever invoked, always either
changes point or outputs <Pattern not found> message.  So it appears
that the command reported to be bound to that key is not invoked at
all.

dispatched randomly [key bindings reported incorrectly]

[Ilya N. Golubev]

Closed wrt mismatch between reported key bindings and actual
dispatching of events.  `viper-search-Next' is actually called as
`describe-bindings' and `describe-key' report.  So do other commands
from different keymaps - and bindings appear a random mix of them.

That is, `viper-vi-basic-minor-mode' is before `view-mode' in
`minor-mode-map-alist'.  Still `view-mode' bindings override those of
`viper-vi-basic-minor-mode', both as reported by `describe-bindings'
and as keys are actually dispatched.  So bindings of ascii characters
are highly inconsistent and appear random.
 
`viper-search-Next' actually did nothing, and it is a bug in viper: it
may set its internal variables so.

Re: dispatched randomly [key bindings reported incorrectly]

[Kevin Rodgers]

Ilya N. Golubev wrote:
> That is, `viper-vi-basic-minor-mode' is before `view-mode' in
> `minor-mode-map-alist'.  Still `view-mode' bindings override those of
> `viper-vi-basic-minor-mode', both as reported by `describe-bindings'
> and as keys are actually dispatched.  So bindings of ascii characters
> are highly inconsistent and appear random.

That is disturbing.  But I just came across this in the Active Keymaps 
node of the Emacs Lisp manual:

|    Normally the active keymaps are the `keymap' property keymap, the
| keymaps of any enabled minor modes, the current buffer's local keymap,
| and the global keymap, in that order.  Therefore, Emacs searches for
| each input key sequence in all these keymaps.  Here is a pseudo-Lisp
| description of how this process works:
|
|      (or (if overriding-terminal-local-map
|              (FIND-IN overriding-terminal-local-map)
|            (if overriding-local-map
|                (FIND-IN overriding-local-map)
|              (or (FIND-IN (get-text-property (point) 'keymap))
|                  (FIND-IN-ANY emulation-mode-map-alists)
|                  (FIND-IN-ANY minor-mode-overriding-map-alist)
|                  (FIND-IN-ANY minor-mode-map-alist)
|                  (if (get-text-property (point) 'local-map))
|                      (FIND-IN (get-text-property (point) 'local-map))
|                    (FIND-IN (current-local-map))))))
|          (FIND-IN (current-global-map)))
|
| Here, the pseudo-function FIND-IN means to look up the key sequence in
| a single map, and FIND-IN-ANY means to search the appropriate keymaps
| from an alist.  (Searching a single keymap for a binding is called "key
| lookup"; see *Note Key Lookup::.)

Does `C-h v overriding-local-map', `C-h v emulation-mode-map-alists', or
`C-h v minor-mode-overriding-map-alist' explain the behavior you see?

-- 
Kevin