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

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

[Drew Adams]

Caveat: I'm not real clear on what the behavior is supposed to be.  See
doc bug #10872.  This bug report is about the behavior, not the doc.  It
seems to differ from what I understand by reading the doc.
 
emacs -Q
 
(defun foobar (&optional n) "@@@@"
  (interactive) (forward-line 0))
 
(defvar foo-mode-map
  (let ((map  (make-sparse-keymap)))
    (define-key map [remap forward-char] 'foobar)
    map))
 
(define-minor-mode foo-mode "foo doc" nil nil foo-mode-map
  :global t :init-value nil)
 
(foo-mode 1)
 
(where-is-internal 'forward-char nil t) ; Returns [6] in Foo mode.
 
In `foo-mode-map', command `forward-char' is remapped to command
`foobar', so in Foo mode all keys normally bound to `forward-char' are
instead (indirectly) bound to `foobar'.
 
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?
 
In GNU Emacs 24.0.93.1 (i386-mingw-nt5.1.2600)
 of 2012-02-15 on MARVIN
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --with-gcc (4.6) --no-opt --enable-checking --cflags
 -ID:/devel/emacs/libs/libXpm-3.5.8/include
 -ID:/devel/emacs/libs/libXpm-3.5.8/src
 -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
 -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
 -ID:/devel/emacs/libs/giflib-4.1.4-1/include
 -ID:/devel/emacs/libs/jpeg-6b-4/include
 -ID:/devel/emacs/libs/tiff-3.8.2-1/include
 -ID:/devel/emacs/libs/gnutls-3.0.9/include'
 

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

[Drew Adams]

ping

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

[Drew Adams]

ping

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

[Drew Adams]

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?
> 

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

[Lars Ingebrigtsen]

"Drew Adams" <drew.adams@oracle.com> writes:

> 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.

This is what Chong added:

The optional 5th arg NO-REMAP alters how command remapping is handled:

- If another command OTHER-COMMAND is remapped to DEFINITION, normally
  search for the bindings of OTHER-COMMAND and include them in the
  returned list.  But if NO-REMAP is non-nil, include the vector
  [remap OTHER-COMMAND] in the returned list instead, without
  searching for those other bindings.

- If DEFINITION is remapped to OTHER-COMMAND, normally return the
  bindings for OTHER-COMMAND.  But if NO-REMAP is non-nil, return the
  bindings for DEFINITION instead, ignoring its remapping.  */)

I'm not sure I understand what you're saying about `where-is-internal'.
Do you have a test case that displays that it's doing something other
then what is documented?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Drew Adams]

> The optional 5th arg NO-REMAP alters how command remapping is handled:
> 
> - If another command OTHER-COMMAND is remapped to DEFINITION, normally
>   search for the bindings of OTHER-COMMAND and include them in the
>   returned list.  But if NO-REMAP is non-nil, include the vector
>   [remap OTHER-COMMAND] in the returned list instead, without
>   searching for those other bindings.
> 
> - If DEFINITION is remapped to OTHER-COMMAND, normally return the
>   bindings for OTHER-COMMAND.  But if NO-REMAP is non-nil, return the
>   bindings for DEFINITION instead, ignoring its remapping.  */)
> 
> I'm not sure I understand what you're saying about `where-is-internal'.
> Do you have a test case that displays that it's doing something other
> then what is documented?

Yes, that newer doc describes what I see, so there is apparently
no behavior bug, wrt that.

Note that this new doc says exactly the opposite of the doc
that I quoted when I filed the bug.  That older doc says:

  It also returns `nil' if COMMAND won't really be run because
  it has been remapped to some other command.

And that is the case here: the remapped command `forward-char'
is not run because its keys have been remapped to `foobar'.
So according to the older doc it should return nil.

  However, if NO-REMAP is non-`nil' `where-is-internal'
  ignores remappings.

That presumably means that remappings (the previous sentence)
are ignored if NO-REMAP is non-nil.  But it is nil in the
test case, so presumably remappings are not to be ignored
and the preceding sentence applies: nil should be returned.

The newer doc describes what I reported.  So yes, this can
be closed now.