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'