* bug#10875: 24.0.93; `where-is-internal' and command remapping
@ 2012-02-23 18:16 Drew Adams
2012-03-10 15:29 ` Drew Adams
2012-07-21 21:59 ` Drew Adams
0 siblings, 2 replies; 6+ messages in thread
From: Drew Adams @ 2012-02-23 18:16 UTC (permalink / raw)
To: 10875
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'
^ permalink raw reply [flat|nested] 6+ messages in thread* bug#10875: 24.0.93; `where-is-internal' and command remapping 2012-02-23 18:16 bug#10875: 24.0.93; `where-is-internal' and command remapping Drew Adams @ 2012-03-10 15:29 ` Drew Adams 2012-04-22 23:00 ` Drew Adams 2012-07-21 21:59 ` Drew Adams 1 sibling, 1 reply; 6+ messages in thread From: Drew Adams @ 2012-03-10 15:29 UTC (permalink / raw) To: 10875 ping ^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#10875: 24.0.93; `where-is-internal' and command remapping 2012-03-10 15:29 ` Drew Adams @ 2012-04-22 23:00 ` Drew Adams 0 siblings, 0 replies; 6+ messages in thread From: Drew Adams @ 2012-04-22 23:00 UTC (permalink / raw) To: 10875 ping ^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#10875: 24.0.93; `where-is-internal' and command remapping 2012-02-23 18:16 bug#10875: 24.0.93; `where-is-internal' and command remapping Drew Adams 2012-03-10 15:29 ` Drew Adams @ 2012-07-21 21:59 ` Drew Adams 2016-04-28 13:46 ` bug#10872: " Lars Ingebrigtsen 1 sibling, 1 reply; 6+ messages in thread From: Drew Adams @ 2012-07-21 21:59 UTC (permalink / raw) To: 10875; +Cc: 'Chong Yidong' 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? > ^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#10872: bug#10875: 24.0.93; `where-is-internal' and command remapping 2012-07-21 21:59 ` Drew Adams @ 2016-04-28 13:46 ` Lars Ingebrigtsen 2016-05-01 20:30 ` Drew Adams 0 siblings, 1 reply; 6+ messages in thread From: Lars Ingebrigtsen @ 2016-04-28 13:46 UTC (permalink / raw) To: Drew Adams; +Cc: 10872, 'Chong Yidong', 10875 "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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#10872: bug#10875: 24.0.93; `where-is-internal' and command remapping 2016-04-28 13:46 ` bug#10872: " Lars Ingebrigtsen @ 2016-05-01 20:30 ` Drew Adams 0 siblings, 0 replies; 6+ messages in thread From: Drew Adams @ 2016-05-01 20:30 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 10872, Chong Yidong, 10875 > 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-05-01 20:30 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-02-23 18:16 bug#10875: 24.0.93; `where-is-internal' and command remapping Drew Adams 2012-03-10 15:29 ` Drew Adams 2012-04-22 23:00 ` Drew Adams 2012-07-21 21:59 ` Drew Adams 2016-04-28 13:46 ` bug#10872: " Lars Ingebrigtsen 2016-05-01 20:30 ` Drew Adams
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).