unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: 10875@debbugs.gnu.org
Subject: bug#10875: 24.0.93; `where-is-internal' and command remapping
Date: Thu, 23 Feb 2012 10:16:59 -0800	[thread overview]
Message-ID: <500CA4A40EBF4D9E8A9C18A4AD5F0737@us.oracle.com> (raw)

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'
 






             reply	other threads:[~2012-02-23 18:16 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-23 18:16 Drew Adams [this message]
2012-03-10 15:29 ` bug#10875: 24.0.93; `where-is-internal' and command remapping 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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=500CA4A40EBF4D9E8A9C18A4AD5F0737@us.oracle.com \
    --to=drew.adams@oracle.com \
    --cc=10875@debbugs.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).