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