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.