bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#10875: 24.0.93; `where-is-internal' and command remapping


From: Drew Adams
Subject: bug#10875: 24.0.93; `where-is-internal' and command remapping
Date: Sat, 21 Jul 2012 14:59:16 -0700

ping.

No one has ever responded to this bug.  It was merged with 10872 for some
reason, and that bug was supposedly fixed.

But that was a DOC bug and this is a product BEHAVIOR bug.  I do not see
anything fixed for this bug: `where-is-internal' still returns the wrong result.

Here is an example of how the `where-is-internal' behavior is
incorrect/misleading.

I have code that executes a command the user types (i.e., like `M-x' does).  It
uses this:

(where-is-internal COMMAND overriding-local-map t 'NOINDIRECT)

to check whether the COMMAND is bound to a key sequence.  If so, it reminds the
user, showing the key sequence.

Suppose command foo is initially bound to C-f, but has been remapped to command
bar.  It is now bar that can be invoked using the keys, such as C-f, that foo
was originally bound to.

If the user types `foo' as input, to invoke command `foo', s?he should not be
informed that she can invoke `foo' using `C-f' -- because she cannot.

I am calling `where-is-internal' with non-nil NOINDIRECT arg. My interpretation
of the doc is that non-nil NOINDIRECT means return the current bindings of foo,
not including those of bar, i.e., ignoring the remapping to bar.  Since foo has
been remapped to bar, it has no current bindings (apart from the remap
bindings), so `w-i-i' should return nil.

"Ignoring its remapping" in the doc cannot mean to return the _original_
bindings of foo, before remapping - that would make no sense (IMHO), since the
result would be the same as for nil NOINDIRECT.  It can only reasonably mean to
return the _current_ bindings of foo, apart from any remap bindings.  Isn't that
the point of this arg: to let you exclude any indirect remapped bindings?

For example, there are no bindings for the command `switch-to-buffer', because
it has been remapped to `icicle-buffer'.  And yet that call to
`where-is-internal' for `switch-to-buffer' returns [24 98], which means `C-x b'.

Can someone please explain how this is not a bug, or please fix it if it is?
Thx.

> Sent: Wednesday, June 20, 2012 6:21 AM
> 
> ping
> 
> > Sent: Thursday, February 23, 2012 10:17 AM
> ...
> > The doc for `where-is-internal' says:
> >  
> >  When command remapping is in effect (*note Remapping Commands::),
> >  `where-is-internal' figures out when a command will be run due to
> >  remapping and reports keys accordingly.  It also returns `nil' if
> >  COMMAND won't really be run because it has been remapped to some
> >  other command.  However, if NO-REMAP is non-`nil'.
> >  `where-is-internal' ignores remappings.
> >  
> > I interpret the next-to-last sentence as implying that, in Foo mode,
> > `where-is-internal' should return nil for `forward-char'.  
> Instead, it
> > returns [6], meaning `C-f'.  Is this not a bug?  If not, what am I
> > missing?
> 






reply via email to

[Prev in Thread] Current Thread [Next in Thread]