* bug#25612: 26.0.50; Slightly suboptimal message for disabled commands
@ 2017-02-03 12:34 Philipp Stephani
2017-02-03 13:19 ` Eli Zaretskii
0 siblings, 1 reply; 9+ messages in thread
From: Philipp Stephani @ 2017-02-03 12:34 UTC (permalink / raw)
To: 25612
Run M-x erase-buffer. The *Disabled Command* buffer that shows up
contains
You have typed RET, invoking disabled command erase-buffer.
This should rather be
You have typed M-x erase-buffer RET, invoking disabled command
erase-buffer.
The RET alone of course didn't invoke the command, it just happens to be
the last keystroke, so this message might be somewhat confusing.
In GNU Emacs 26.0.50.42 (x86_64-unknown-linux-gnu, GTK+ Version 3.10.8)
of 2017-02-03 built on localhost
Repository revision: e080d019f41d2738ba0db721c1b89ea57413439b
Windowing system distributor 'The X.Org Foundation', version 11.0.11501000
System Description: Ubuntu 14.04 LTS
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Configured using:
'configure --with-modules --enable-checking
--enable-check-lisp-object-type 'CFLAGS=-ggdb3 -O0''
Configured features:
XPM JPEG TIFF GIF PNG SOUND GSETTINGS NOTIFY GNUTLS FREETYPE XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 MODULES
Important settings:
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
Major mode: Lisp Interaction
Minor modes in effect:
tooltip-mode: t
global-eldoc-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
Load-path shadows:
None found.
Features:
(shadow sort mail-extr emacsbug message subr-x puny seq byte-opt gv
bytecomp byte-compile cl-extra help-mode cconv cl-loaddefs pcase cl-lib
dired dired-loaddefs format-spec rfc822 mml easymenu mml-sec
password-cache epa derived epg epg-config gnus-util rmail rmail-loaddefs
mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr
mail-utils time-date mule-util tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow isearch timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript case-table epa-hook jka-cmpr-hook help
simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs button
faces cus-face macroexp files text-properties overlay sha1 md5 base64
format env code-pages mule custom widget hashtable-print-readable
backquote inotify dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty
make-network-process emacs)
Memory information:
((conses 16 97811 8600)
(symbols 48 20258 1)
(miscs 40 331 131)
(strings 32 18045 4554)
(string-bytes 1 593455)
(vectors 16 14074)
(vector-slots 8 472888 6594)
(floats 8 182 70)
(intervals 56 218 0)
(buffers 976 12)
(heap 1024 29048 1021))
--
Google Germany GmbH
Erika-Mann-Straße 33
80636 München
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
Diese E-Mail ist vertraulich. Wenn Sie nicht der richtige Adressat sind,
leiten Sie diese bitte nicht weiter, informieren Sie den Absender und löschen
Sie die E-Mail und alle Anhänge. Vielen Dank.
This e-mail is confidential. If you are not the right addressee please do not
forward it, please inform the sender, and please erase this e-mail including
any attachments. Thanks.
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#25612: 26.0.50; Slightly suboptimal message for disabled commands
2017-02-03 12:34 bug#25612: 26.0.50; Slightly suboptimal message for disabled commands Philipp Stephani
@ 2017-02-03 13:19 ` Eli Zaretskii
2017-02-03 14:15 ` Philipp Stephani
0 siblings, 1 reply; 9+ messages in thread
From: Eli Zaretskii @ 2017-02-03 13:19 UTC (permalink / raw)
To: Philipp Stephani; +Cc: 25612
> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Fri, 03 Feb 2017 13:34:09 +0100
>
> Run M-x erase-buffer. The *Disabled Command* buffer that shows up
> contains
>
> You have typed RET, invoking disabled command erase-buffer.
>
> This should rather be
>
> You have typed M-x erase-buffer RET, invoking disabled command
> erase-buffer.
>
> The RET alone of course didn't invoke the command, it just happens to be
> the last keystroke, so this message might be somewhat confusing.
Depending on your POV, it could be argued that RET is the one that
actually invoked the command.
Perhaps the message should avoid showing the key sequence at all?
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#25612: 26.0.50; Slightly suboptimal message for disabled commands
2017-02-03 13:19 ` Eli Zaretskii
@ 2017-02-03 14:15 ` Philipp Stephani
2017-02-03 15:10 ` Eli Zaretskii
0 siblings, 1 reply; 9+ messages in thread
From: Philipp Stephani @ 2017-02-03 14:15 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 25612
[-- Attachment #1: Type: text/plain, Size: 1122 bytes --]
Eli Zaretskii <eliz@gnu.org> schrieb am Fr., 3. Feb. 2017 um 14:19 Uhr:
> > From: Philipp Stephani <p.stephani2@gmail.com>
> > Date: Fri, 03 Feb 2017 13:34:09 +0100
> >
> > Run M-x erase-buffer. The *Disabled Command* buffer that shows up
> > contains
> >
> > You have typed RET, invoking disabled command erase-buffer.
> >
> > This should rather be
> >
> > You have typed M-x erase-buffer RET, invoking disabled command
> > erase-buffer.
> >
> > The RET alone of course didn't invoke the command, it just happens to be
> > the last keystroke, so this message might be somewhat confusing.
>
> Depending on your POV, it could be argued that RET is the one that
> actually invoked the command.
>
> Perhaps the message should avoid showing the key sequence at all?
>
It seems that this is the intention of lines 54 through 62 in novice.el,
but it doesn't seem to work any more.
This is a regression: it still works as expected in Emacs 23.4, but no
longer in Emacs 24.3. Probably something about this-command-keys or
command-execute changed in the meantime so that the code in novice.el no
longer works as expected.
[-- Attachment #2: Type: text/html, Size: 1958 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#25612: 26.0.50; Slightly suboptimal message for disabled commands
2017-02-03 14:15 ` Philipp Stephani
@ 2017-02-03 15:10 ` Eli Zaretskii
2017-02-03 15:54 ` Philipp Stephani
0 siblings, 1 reply; 9+ messages in thread
From: Eli Zaretskii @ 2017-02-03 15:10 UTC (permalink / raw)
To: Philipp Stephani; +Cc: 25612
> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Fri, 03 Feb 2017 14:15:30 +0000
> Cc: 25612@debbugs.gnu.org
>
> Perhaps the message should avoid showing the key sequence at all?
>
> It seems that this is the intention of lines 54 through 62 in novice.el, but it doesn't seem to work any more.
Indeed.
> This is a regression: it still works as expected in Emacs 23.4, but no longer in Emacs 24.3. Probably
> something about this-command-keys or command-execute changed in the meantime so that the code in
> novice.el no longer works as expected.
Yes, this-command-keys returns just "^M" instead of the expected
"\370erase-buffer^M" it returned in Emacs 24.2 and older.
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#25612: 26.0.50; Slightly suboptimal message for disabled commands
2017-02-03 15:10 ` Eli Zaretskii
@ 2017-02-03 15:54 ` Philipp Stephani
2017-02-03 21:16 ` Eli Zaretskii
0 siblings, 1 reply; 9+ messages in thread
From: Philipp Stephani @ 2017-02-03 15:54 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 25612
[-- Attachment #1: Type: text/plain, Size: 1239 bytes --]
Eli Zaretskii <eliz@gnu.org> schrieb am Fr., 3. Feb. 2017 um 16:10 Uhr:
>
> > This is a regression: it still works as expected in Emacs 23.4, but no
> longer in Emacs 24.3. Probably
> > something about this-command-keys or command-execute changed in the
> meantime so that the code in
> > novice.el no longer works as expected.
>
> Yes, this-command-keys returns just "^M" instead of the expected
> "\370erase-buffer^M" it returned in Emacs 24.2 and older.
>
git bisect says
b593d6a999b21dfee6939b24866a5ec6fbe7d11b is the first bad commit
commit b593d6a999b21dfee6939b24866a5ec6fbe7d11b
Author: Aaron S. Hawley <aaron.s.hawley@gmail.com>
Date: Tue May 1 12:10:02 2012 -0400
Reimplement execute-extended-command in Elisp.
* src/keyboard.c (Fexecute_extended_command, Vsuggest_key_bindings):
Move to simple.el.
* lisp/simple.el (suggest-key-bindings, execute-extended-command):
Move from keyboard.c.
:040000 040000 980a3efdb92bf89c1042883830e7fbd1da063f3e
997099bae8bf4663aed645559b102345912f19fa M lisp
:040000 040000 832414759411034e7cea2c694fdb77273c422b05
ccf76976dd740fc43ccf84c35ddaf9efe19d5ec2 M src
That looks reasonable given that it touches code closely related to the
disabled command functionality.
[-- Attachment #2: Type: text/html, Size: 2049 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#25612: 26.0.50; Slightly suboptimal message for disabled commands
2017-02-03 15:54 ` Philipp Stephani
@ 2017-02-03 21:16 ` Eli Zaretskii
2017-02-10 9:00 ` Eli Zaretskii
0 siblings, 1 reply; 9+ messages in thread
From: Eli Zaretskii @ 2017-02-03 21:16 UTC (permalink / raw)
To: Philipp Stephani; +Cc: 25612
> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Fri, 03 Feb 2017 15:54:06 +0000
> Cc: 25612@debbugs.gnu.org
>
> Yes, this-command-keys returns just "^M" instead of the expected
> "\370erase-buffer^M" it returned in Emacs 24.2 and older.
>
> git bisect says
>
> b593d6a999b21dfee6939b24866a5ec6fbe7d11b is the first bad commit
> commit b593d6a999b21dfee6939b24866a5ec6fbe7d11b
> Author: Aaron S. Hawley <aaron.s.hawley@gmail.com>
> Date: Tue May 1 12:10:02 2012 -0400
>
> Reimplement execute-extended-command in Elisp.
> * src/keyboard.c (Fexecute_extended_command, Vsuggest_key_bindings):
> Move to simple.el.
> * lisp/simple.el (suggest-key-bindings, execute-extended-command):
> Move from keyboard.c.
Yes, when execute-extended-command was reimplemented in Lisp, the
special code which produced "\370erase-buffer^M" was lost.
Does the change below produce good results? If so, can anyone suggest
a more elegant way of squirreling M-x into this-command-keys?
diff --git a/lisp/simple.el b/lisp/simple.el
index 441713a..c0dad2d 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -1733,6 +1733,9 @@ execute-extended-command
(where-is-internal function overriding-local-map t))))
(unless (commandp function)
(error "`%s' is not a valid command name" command-name))
+ ;; Some features, such as novice.el, rely on this-command-keys
+ ;; including M-x COMMAND-NAME RET.
+ (set--this-command-keys (concat "\M-x" (symbol-name function) "\r"))
(setq this-command function)
;; Normally `real-this-command' should never be changed, but here we really
;; want to pretend that M-x <cmd> RET is nothing more than a "key
diff --git a/src/keyboard.c b/src/keyboard.c
index a86e7c5..b1eeb03 100644
--- a/src/keyboard.c
+++ b/src/keyboard.c
@@ -10001,6 +10001,28 @@ See also `this-command-keys-vector'. */)
XVECTOR (this_command_keys)->contents);
}
+DEFUN ("set--this-command-keys", Fset__this_command_keys,
+ Sset__this_command_keys, 1, 1, 0,
+ doc: /* Set the vector to be returned by `this-command-keys'.
+The argument KEYS must be a string.
+Internal use only. */)
+ (Lisp_Object keys)
+{
+ CHECK_STRING (keys);
+
+ this_command_key_count = 0;
+ this_single_command_key_start = 0;
+ int key0 = SREF (keys, 0);
+
+ if (key0 == 248)
+ add_command_key (make_number ('x' | meta_modifier));
+ else
+ add_command_key (make_number (key0));
+ for (int i = 1; i < SCHARS (keys); i++)
+ add_command_key (make_number (SREF (keys, i)));
+ return Qnil;
+}
+
DEFUN ("this-command-keys-vector", Fthis_command_keys_vector, Sthis_command_keys_vector, 0, 0, 0,
doc: /* Return the key sequence that invoked this command, as a vector.
However, if the command has called `read-key-sequence', it returns
@@ -11211,6 +11233,7 @@ syms_of_keyboard (void)
defsubr (&Sthis_command_keys_vector);
defsubr (&Sthis_single_command_keys);
defsubr (&Sthis_single_command_raw_keys);
+ defsubr (&Sset__this_command_keys);
defsubr (&Sclear_this_command_keys);
defsubr (&Ssuspend_emacs);
defsubr (&Sabort_recursive_edit);
^ permalink raw reply related [flat|nested] 9+ messages in thread
* bug#25612: 26.0.50; Slightly suboptimal message for disabled commands
2017-02-03 21:16 ` Eli Zaretskii
@ 2017-02-10 9:00 ` Eli Zaretskii
2017-02-12 15:12 ` Philipp Stephani
0 siblings, 1 reply; 9+ messages in thread
From: Eli Zaretskii @ 2017-02-10 9:00 UTC (permalink / raw)
To: p.stephani2; +Cc: 25612-done
> Date: Fri, 03 Feb 2017 23:16:27 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 25612@debbugs.gnu.org
>
> > From: Philipp Stephani <p.stephani2@gmail.com>
> > Date: Fri, 03 Feb 2017 15:54:06 +0000
> > Cc: 25612@debbugs.gnu.org
> >
> > Yes, this-command-keys returns just "^M" instead of the expected
> > "\370erase-buffer^M" it returned in Emacs 24.2 and older.
> >
> > git bisect says
> >
> > b593d6a999b21dfee6939b24866a5ec6fbe7d11b is the first bad commit
> > commit b593d6a999b21dfee6939b24866a5ec6fbe7d11b
> > Author: Aaron S. Hawley <aaron.s.hawley@gmail.com>
> > Date: Tue May 1 12:10:02 2012 -0400
> >
> > Reimplement execute-extended-command in Elisp.
> > * src/keyboard.c (Fexecute_extended_command, Vsuggest_key_bindings):
> > Move to simple.el.
> > * lisp/simple.el (suggest-key-bindings, execute-extended-command):
> > Move from keyboard.c.
>
> Yes, when execute-extended-command was reimplemented in Lisp, the
> special code which produced "\370erase-buffer^M" was lost.
>
> Does the change below produce good results? If so, can anyone suggest
> a more elegant way of squirreling M-x into this-command-keys?
No further comments, so I pushed my kludgey solution, and I'm marking
this bug done.
Thanks.
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#25612: 26.0.50; Slightly suboptimal message for disabled commands
2017-02-10 9:00 ` Eli Zaretskii
@ 2017-02-12 15:12 ` Philipp Stephani
2017-02-18 10:31 ` Eli Zaretskii
0 siblings, 1 reply; 9+ messages in thread
From: Philipp Stephani @ 2017-02-12 15:12 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 25612-done
[-- Attachment #1: Type: text/plain, Size: 1568 bytes --]
Eli Zaretskii <eliz@gnu.org> schrieb am Fr., 10. Feb. 2017 um 10:00 Uhr:
> > Date: Fri, 03 Feb 2017 23:16:27 +0200
> > From: Eli Zaretskii <eliz@gnu.org>
> > Cc: 25612@debbugs.gnu.org
> >
> > > From: Philipp Stephani <p.stephani2@gmail.com>
> > > Date: Fri, 03 Feb 2017 15:54:06 +0000
> > > Cc: 25612@debbugs.gnu.org
> > >
> > > Yes, this-command-keys returns just "^M" instead of the expected
> > > "\370erase-buffer^M" it returned in Emacs 24.2 and older.
> > >
> > > git bisect says
> > >
> > > b593d6a999b21dfee6939b24866a5ec6fbe7d11b is the first bad commit
> > > commit b593d6a999b21dfee6939b24866a5ec6fbe7d11b
> > > Author: Aaron S. Hawley <aaron.s.hawley@gmail.com>
> > > Date: Tue May 1 12:10:02 2012 -0400
> > >
> > > Reimplement execute-extended-command in Elisp.
> > > * src/keyboard.c (Fexecute_extended_command, Vsuggest_key_bindings):
> > > Move to simple.el.
> > > * lisp/simple.el (suggest-key-bindings, execute-extended-command):
> > > Move from keyboard.c.
> >
> > Yes, when execute-extended-command was reimplemented in Lisp, the
> > special code which produced "\370erase-buffer^M" was lost.
> >
> > Does the change below produce good results? If so, can anyone suggest
> > a more elegant way of squirreling M-x into this-command-keys?
>
> No further comments, so I pushed my kludgey solution, and I'm marking
> this bug done.
>
>
Sorry for not responding earlier, the fix works fine. My only nitpick would
be to add a comment for the magic number 248 in the code. I can guess it's
0x80 | 'x', but that might not be obvious to casual readers.
[-- Attachment #2: Type: text/html, Size: 3117 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#25612: 26.0.50; Slightly suboptimal message for disabled commands
2017-02-12 15:12 ` Philipp Stephani
@ 2017-02-18 10:31 ` Eli Zaretskii
0 siblings, 0 replies; 9+ messages in thread
From: Eli Zaretskii @ 2017-02-18 10:31 UTC (permalink / raw)
To: Philipp Stephani; +Cc: 25612
> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Sun, 12 Feb 2017 15:12:31 +0000
> Cc: 25612-done@debbugs.gnu.org
>
> No further comments, so I pushed my kludgey solution, and I'm marking
> this bug done.
>
> Sorry for not responding earlier, the fix works fine. My only nitpick would be to add a comment for the magic
> number 248 in the code. I can guess it's 0x80 | 'x', but that might not be obvious to casual readers.
Thanks, I added a comment there.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2017-02-18 10:31 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-02-03 12:34 bug#25612: 26.0.50; Slightly suboptimal message for disabled commands Philipp Stephani
2017-02-03 13:19 ` Eli Zaretskii
2017-02-03 14:15 ` Philipp Stephani
2017-02-03 15:10 ` Eli Zaretskii
2017-02-03 15:54 ` Philipp Stephani
2017-02-03 21:16 ` Eli Zaretskii
2017-02-10 9:00 ` Eli Zaretskii
2017-02-12 15:12 ` Philipp Stephani
2017-02-18 10:31 ` Eli Zaretskii
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).