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

[Drew Adams <drew.adams@oracle.com>]

> > Currently we say only that it is shadowed by another "mode".
> 
> Isn't that wording what the commit that we had pointed you at changed?
> The text doesn't speak about a "mode" any more.

Yes.  You replied to a message from Saturday, where I
was referring to the state before the fix (I hadn't
yet seen the fix).

See my mail from this morning, which speaks about the
after-fix state.

> And is the word "shadowed" really unclear?  It's used in the manual, but
> not officially defined.  To me it was clear from the beginning what it
> means.

It can be understood, yes.  The problem is that what
shadows the key is unclear.  And the listing of keys
is apparently by keymap, with no indication of that
or any indication of which keymap is parent etc.

Listing (grouping) by keymaps is OK, if that's made clear.

Alternatively, listing by keys would also be OK.  In
that case, multiple bindings for the same key would
be listed next to each other, and it's enough to say,
for a given key, that it's shadowed - because then it's
obvious which key does the shadowing.

But in that alternative listing it's not clear why
this one shadows that one, because there's no mention
or identification of their keymaps and their relation.

> I agree that it could be useful to tell what causes the shadowing,
> though there are ways for the user to find out (e.g. C-h k).

Please see my mail from this morning about this.

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=14086#70