bug#14086: 24.3.50; `substitute-command-keys': inappropriate "(that binding is currently shadowed by another mode)"

[Drew Adams]

> > But near the end of the listing (not at all near that entry), I see this
> > other entry for `M-r':
> >
> >  M-r             previous-matching-history-element
> >    (that binding is currently shadowed by another mode)
> >
> > That makes no sense, or is at least misleading.  There is no special
> > "mode" that I am aware of that is involved here, for one thing.  And I
> > don't see how the `previous-matching-history-element' binding is
> > "shadowed", whether by "another mode" or any other way.  `M-r' is simply
> > bound to `icicle-roundup' in this keymap - it is not bound to
> > `previous-matching-history-element' in this map, AFAIK.
> 
> The test case is this:
> 
> (define-key minibuffer-local-completion-map (kbd "M-r") 'icicle-roundup)
> (substitute-command-keys "\\{minibuffer-local-completion-map}")
> 
> "key             binding
> ---             -------
> 
> C-g           abort-recursive-edit
> [...]
> M-r           icicle-roundup
> [...]
> M-r           previous-matching-history-element
>   (that binding is currently shadowed by another mode)
> "
> 
> That is pretty confusing -- I didn't even know that you could have the
> same key binding twice in a keymap?

I'm guessing that comes from `bindings.el' binding `M-r' to 
`previous-matching-history-element' in `minibuffer-local-map', and Icicles 
binding `M-r' to `icicle-roundup' in `minibuffer-local-completion-map'.  And 
this is true:

(eq minibuffer-local-map
    (keymap-parent minibuffer-local-completion-map))

I'm guessing that's what all the "shadowing" is about.  `icicle-roundup' is the 
actual binding, in `minibuffer-local-completion-map'.  Why, in a listing of 
`minibuffer-local-completion-map', we show the other command as also being 
bound to `M-r', I don't know.  I don't mean how we do that, but why - for users?