From: Nick OBrien via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 69246@debbugs.gnu.org
Subject: bug#69246: 30.0.50; persistent key input delay after using vc commands in pgtk
Date: Wed, 21 Feb 2024 02:19:11 +0000 [thread overview]
Message-ID: <zZOWHnJkat2TCMAT8CMUqzHsy4_4V27-p8pFock4hvC-dV0op-BLA2GxxVdQEqTpBMWULwIJ6Zg0x7iDRA3hxwsPenP2aXpMGevRq9vx_cA=@proton.me> (raw)
In-Reply-To: <86a5nxqgio.fsf@gnu.org>
> Thanks, but I don't see anything here which gives a hint why you see
> the lags, nor even evidence that there was a lag. Maybe try leaning
> on a key for 20 seconds, so that the keyboard auto-repeat produces
> keypresses at high frequency -- maybe then the profile will tell
> something.
I followed the steps in the original bug report to reproduce the lag, then I did
the following:
C-x b bar RET
C-u 1000 C-q C-j
M-<
M-x profiler-start RET RET
C-f ; held down for about 25 seconds
M-x profiler-stop RET
552 82% - redisplay_internal (C function)
18 2% - eval
11 1% - if
8 1% frame-parameter
2 0% - display-graphic-p
1 0% framep-on-display
5 0% - mode-line-eol-desc
3 0% coding-system-eol-type-mnemonic
1 0% mode-line-window-control
5 0% file-remote-p
4 0% - mode-line-default-help-echo
3 0% - window-at-side-p
2 0% - window-pixel-edges
2 0% window-edges
1 0% window-normalize-window
1 0% minibuffer-window-active-p
3 0% - redisplay--pre-redisplay-functions
1 0% window-buffer
53 7% - command-execute
40 5% - byte-code
40 5% - read-extended-command
40 5% - read-extended-command-1
40 5% - completing-read-default
9 1% redisplay_internal (C function)
3 0% - funcall-interactively
2 0% execute-extended-command
3 0% interactive-form
3 0% handle-shift-selection
42 6% Automatic GC
9 1% - undo-auto--add-boundary
8 1% - undo-auto--boundaries
3 0% add-to-list
2 0% - undo-auto--ensure-boundary
1 0% undo-auto--needs-boundary-p
5 0% - tooltip-hide
2 0% tooltip-cancel-delayed-tip
4 0% clear-minibuffer-message
2 0% internal-timer-start-idle
2 0% - internal-echo-keystrokes-prefix
1 0% #<compiled -0x13309019554cae09>
0 0% ...
I did the same thing but longer (after restarting Emacs and reproducing the lag):
C-x b bar RET
C-u 2000 C-q C-j
M-<
M-x profiler-start RET RET
C-f ; held down for about 60 seconds
M-x profiler-stop RET
1644 89% - redisplay_internal (C function)
28 1% - eval
18 0% - if
14 0% - frame-parameter
1 0% quote
3 0% - display-graphic-p
3 0% framep-on-display
5 0% - mode-line-eol-desc
2 0% coding-system-eol-type-mnemonic
2 0% - unless
2 0% #<compiled -0x1d70b361daad23ef>
1 0% mode-line-window-control
24 1% file-remote-p
10 0% - mode-line-default-help-echo
3 0% - window-at-side-p
1 0% - window-pixel-edges
1 0% window-edges
2 0% minibuffer-window-active-p
9 0% - redisplay--pre-redisplay-functions
3 0% - run-hook-with-args
2 0% redisplay--update-region-highlight
1 0% selected-window
1 0% window-buffer
96 5% Automatic GC
57 3% - command-execute
41 2% - byte-code
41 2% - read-extended-command
41 2% - read-extended-command-1
41 2% - completing-read-default
7 0% redisplay_internal (C function)
1 0% - minibuffer-mode
1 0% - run-mode-hooks
1 0% - run-hooks
1 0% - global-eldoc-mode-enable-in-buffers
1 0% - turn-on-eldoc-mode
1 0% eldoc--supported-p
3 0% interactive-form
3 0% handle-shift-selection
2 0% - funcall-interactively
1 0% forward-char
15 0% - clear-minibuffer-message
1 0% timerp
11 0% - undo-auto--add-boundary
11 0% - undo-auto--boundaries
6 0% - undo-auto--ensure-boundary
3 0% undo-auto--needs-boundary-p
5 0% add-to-list
6 0% - internal-echo-keystrokes-prefix
1 0% #<compiled -0x13309019554cae09>
3 0% - internal-timer-start-idle
3 0% timerp
3 0% - tooltip-hide
1 0% tooltip-cancel-delayed-tip
2 0% - help-command-error-confusable-suggestions
2 0% - substitute-command-keys
1 0% generate-new-buffer
1 0% - #<compiled 0x119bbf11827c0b18>
1 0% - kill-buffer
1 0% - replace-buffer-in-windows
1 0% window-normalize-buffer
0 0% ...
Just to be clear about the lag I'm observing, here's a couple scenarios:
In the first one, say "abc" is already in a buffer. At time 0, I press the "d"
key and hold it. After 300 ms, I release the "d" key. Here's what the buffer
looks like at various times (the times aren't exact, they're for demonstration):
| Time (ms) | Key Event | Buffer (no lag) | Buffer (lag) |
|-----------+-----------+-----------------+--------------|
| 0 | "d" down | abc | abc |
| 1 | | abcd | abc |
| 100 | | abcd | abc |
| 200 | | abcd | abcd | <- "d" appears after lag
| 300 | "d" up | abcd | abcd |
However, "d" always appears immediately when I release the key. In the second
scenario, I release "d" after 10 ms:
| Time (ms) | Key Event | Buffer (no lag) | Buffer (lag) |
|-----------+-----------+-----------------+--------------|
| 0 | "d" down | abc | abc |
| 1 | | abcd | abc |
| 10 | "d" up | abcd | abc |
| 11 | | abcd | abcd | <- "d" appears as soon
| 100 | | abcd | abcd | as the key is released
In other words, if I press and release a key at the same time, the lag isn't
noticeable. I only see the lag when I press a key and don't release it. When a
key is held down and auto-repeating, I don't notice a drastic speed difference
with or without the lag. The appearing characters just look choppier when the
lag is occurring.
I realize this is an awkward bug to explain and reproduce, thanks for bearing
with me. More suggestions on how to narrow down the cause would be appreciated.
next prev parent reply other threads:[~2024-02-21 2:19 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-17 20:38 bug#69246: 30.0.50; persistent key input delay after using vc commands in pgtk Nick OBrien via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-18 19:04 ` Eli Zaretskii
2024-02-18 19:21 ` Nick OBrien via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-18 19:31 ` Eli Zaretskii
2024-02-18 20:36 ` Nick OBrien via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-19 3:28 ` Eli Zaretskii
2024-02-21 2:19 ` Nick OBrien via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2024-02-21 12:41 ` Eli Zaretskii
2024-02-21 12:49 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-21 16:09 ` Nick OBrien via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-22 1:20 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-22 6:45 ` Eli Zaretskii
2024-02-22 8:02 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-22 8:23 ` Eli Zaretskii
2024-02-22 8:51 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-24 22:24 ` Nick OBrien via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-25 5:55 ` Eli Zaretskii
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='zZOWHnJkat2TCMAT8CMUqzHsy4_4V27-p8pFock4hvC-dV0op-BLA2GxxVdQEqTpBMWULwIJ6Zg0x7iDRA3hxwsPenP2aXpMGevRq9vx_cA=@proton.me' \
--to=bug-gnu-emacs@gnu.org \
--cc=69246@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=nick4f42@proton.me \
/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).