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

Previous Next

Full log

View this message in rfc822 format

From: Drew Adams <drew.adams <at> oracle.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 14086 <at> debbugs.gnu.org
Subject: bug#14086: 24.3.50; `substitute-command-keys': inappropriate "(that binding is currently shadowed by another mode)"
Date: Sun, 4 Oct 2020 10:40:55 -0700 (PDT)

> > seems you treated this in 64d2e5a7a "Make shadowing warning in
> > describe_map less confusing".  Contended enough to close this report?
> 
> Yeah I think so; closing.

I don't have a way of seeing the change you made.
Can you please describe it here or include the
patch here?  Usually a patch is included in the
bug thread, and it's then directly accessible
from the thread on debugs.gnu.org.  A reference
like "64d2e5a7a" means nothing to me.

Wrt the confusion that this bug is about:

I think that one of the following things should
happen, or something else that takes care of the
same problem of listing the same key twice, and
not together, and with no labeled grouping of
the different keymaps (parent, child):

* List the duplicate keys next to each other, with
  the unshadowed one first.

  That makes clear (a) that shadowing occurs, and
  (b) which shadows the other (given the note for
  the shadowed one).

  It doesn't, however, by itself make clear what
  shadowing is, and that there are multiple keymaps
  involved, with inheritance causing the "shadowing".

OR ELSE

* List the keys of a given keymap (parent or child)
  together, as is apparently (?) done now, but label
  them as such.  IOW, label each of the keymap listings,
  and say which keymap's keys shadow the other's.

  And clearly label a shadowed key binding with the
  command that shadows it.  And preferably include a
  link to that command's line in the listing (since
  it is far away, in the other keymap's listing).

If neither of those, or similar, is done, then I don't
think this bug should be closed.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.