From: Lars Ingebrigtsen <larsi@gnus.org>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: 21867@debbugs.gnu.org, zkanfer@gmail.com
Subject: bug#21867: 25.0.50; lossage's log doesn't treat characters read by read-char as separate commands
Date: Sat, 03 Aug 2019 14:13:49 +0200 [thread overview]
Message-ID: <87wofujvk2.fsf@mouse.gnus.org> (raw)
In-Reply-To: <jwvblx7tjo7.fsf-monnier+emacs@gnu.org> (Stefan Monnier's message of "Fri, 02 Aug 2019 16:16:37 -0400")
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> So I think maybe a better way to look at it is to add marker
> pseudo-events like `end-of-command` (e.g. after running
> post-command-hook), so we can discover that `a` was processed as part of
> the execution of the command bound to `C-x C-e` rather than as part of
> the sequence of events that triggered view-lossage.
Makes sense. With the following patch I get:
24 5 (nil . eval-last-sexp) 97 end-of-command
in recent_keys. `view-lossage' could use this to output this as
C-x C-e a ;; eval-last-sexp
It does make the recent_keys list even more... uhm... eccentric, I
guess. And during typical text entry, there'll be slightly more memory
usage:
72 (nil . self-insert-command) end-of-command
101 (nil . self-insert-command) end-of-command
If this approach makes sense, I can fix up view-lossage to interpret the
new structure.
diff --git a/src/keyboard.c b/src/keyboard.c
index db5ca4e547..1a4a7d2711 100644
--- a/src/keyboard.c
+++ b/src/keyboard.c
@@ -307,6 +307,7 @@ #define GROW_RAW_KEYBUF \
static void echo_now (void);
static ptrdiff_t echo_length (void);
+static void record_char (Lisp_Object c);
/* Incremented whenever a timer is run. */
unsigned timers_run;
@@ -1424,6 +1425,8 @@ command_loop_1 (void)
Fcons (Qnil, cmd));
if (++recent_keys_index >= NUM_RECENT_KEYS)
recent_keys_index = 0;
+ /* Mark this as a complete command in recent_keys. */
+ record_char (Qend_of_command);
}
Vthis_command = cmd;
Vreal_this_command = cmd;
@@ -1474,6 +1477,9 @@ command_loop_1 (void)
safe_run_hooks (Qpost_command_hook);
+ /* Mark this as a complete command in recent_keys. */
+ record_char (Qend_of_command);
+
/* If displaying a message, resize the echo area window to fit
that message's size exactly. Do this only if the echo area
window is the minibuffer window of the selected frame. See
@@ -2091,7 +2097,6 @@ show_help_echo (Lisp_Object help, Lisp_Object window, Lisp_Object object,
static Lisp_Object kbd_buffer_get_event (KBOARD **kbp, bool *used_mouse_menu,
struct timespec *end_time);
-static void record_char (Lisp_Object c);
static Lisp_Object help_form_saved_window_configs;
static void
@@ -11069,6 +11074,8 @@ syms_of_keyboard (void)
DEFSYM (Qundefined, "undefined");
+ DEFSYM (Qend_of_command, "end-of-command");
+
/* Hooks to run before and after each command. */
DEFSYM (Qpre_command_hook, "pre-command-hook");
DEFSYM (Qpost_command_hook, "post-command-hook");
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
next prev parent reply other threads:[~2019-08-03 12:13 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-09 4:58 bug#21867: 25.0.50; lossage's log doesn't treat characters read by read-char as separate commands Zachary Kanfer
2019-08-01 18:05 ` Lars Ingebrigtsen
2019-08-01 18:21 ` Eli Zaretskii
2019-08-01 18:41 ` Lars Ingebrigtsen
2019-08-01 18:51 ` Eli Zaretskii
2019-08-01 18:58 ` Lars Ingebrigtsen
2019-08-01 19:18 ` Eli Zaretskii
2019-08-01 19:25 ` Lars Ingebrigtsen
2019-08-02 6:41 ` Eli Zaretskii
2019-08-02 11:19 ` Lars Ingebrigtsen
2019-08-02 12:02 ` Eli Zaretskii
2019-08-02 20:16 ` Stefan Monnier
2019-08-03 12:13 ` Lars Ingebrigtsen [this message]
2019-08-03 21:07 ` Stefan Monnier
2019-08-03 21:14 ` Lars Ingebrigtsen
2019-08-03 21:49 ` Juri Linkov
2019-08-04 11:45 ` Lars Ingebrigtsen
2019-08-04 21:04 ` Juri Linkov
2019-08-04 12:54 ` Stefan Monnier
2019-08-04 19:44 ` Juri Linkov
2019-08-05 18:36 ` Stefan Monnier
2019-08-07 18:31 ` Lars Ingebrigtsen
2019-08-23 1:41 ` Lars Ingebrigtsen
2019-08-05 9:15 ` Lars Ingebrigtsen
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=87wofujvk2.fsf@mouse.gnus.org \
--to=larsi@gnus.org \
--cc=21867@debbugs.gnu.org \
--cc=monnier@iro.umontreal.ca \
--cc=zkanfer@gmail.com \
/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).