GNU bug report logs - #10872
24.0.93; doc of `where-is-internal'

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 10872 in the body.
You can then email your comments to 10872 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: <bug-gnu-emacs <at> gnu.org>
Subject: 24.0.93; doc of `where-is-internal'
Date: Wed, 22 Feb 2012 14:06:10 -0800

1. The doc string says nothing about `overriding-local-map', but that
now changes what a nil value searches.  The doc string is wrong in
saying that nil means search all currently active keymaps.
 
2. The doc string does not say that nil NO-REMAP also means return nil
if COMMAND will not be invoked by any key because it has been remapped.
This is as important as the other characteristic that is mentioned:
"don't search for key sequences that invoke a command which is remapped
to DEFINITION".  In fact, in the manual the latter is not even mentioned
explicitly, while the former is.  The manual is much clearer in this
regard, and no more verbose.
 
3. `(elisp) Scanning Keymaps' says, for NO-REMAP, that "if COMMAND won't
really be run", but it should say will not be invoked by any *key* (it
could be run by `M-x').
 
4. `(elisp) Scanning Keymaps' says to "pass" `(keymap)' if you want to
search only the global map.
 
4a. First, it should make it clear that it is _not_ about passing that
sexp/list, but rather about passing the value of that sexp,
i.e. evaluating that sexp as the arg.  IOW, its value is passed, not the
sexp/list itself.
 
4b. Second, this doc should say something about why it is preferable to
pass an empty keymap by evaluating that sexp, rather than passing the
global keymap by evaluating variable `global-map' or sexp
`(current-global-map)'.  This part of the doc is not clear at all.

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'
 

Message #8 received at 10872 <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> gnu.org>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 10872 <at> debbugs.gnu.org
Subject: Re: bug#10872: 24.0.93; doc of `where-is-internal'
Date: Mon, 23 Apr 2012 11:43:42 +0800

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

> 1. The doc string says nothing about `overriding-local-map', but that
> now changes what a nil value searches.  The doc string is wrong in
> saying that nil means search all currently active keymaps.

Fixed, thanks.

The discussion of the NO-REMAP argument to where-is-internal in the Lisp
manual and the docstring were out of date; that is also fixed now.

Message #21 received at 10872 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 10872 <at> debbugs.gnu.org, 'Chong Yidong' <cyd <at> gnu.org>, 10875 <at> debbugs.gnu.org
Subject: Re: bug#10875: 24.0.93; `where-is-internal' and command remapping
Date: Thu, 28 Apr 2016 15:46:10 +0200

"Drew Adams" <drew.adams <at> 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

Message #26 received at 10872 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 10872 <at> debbugs.gnu.org, Chong Yidong <cyd <at> gnu.org>, 10875 <at> debbugs.gnu.org
Subject: RE: bug#10875: 24.0.93; `where-is-internal' and command remapping
Date: Sun, 1 May 2016 13:30:46 -0700 (PDT)

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

Previous Next

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