bug#69246: 30.0.50; persistent key input delay after using vc commands in pgtk

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]

After opening a file in a git repository with emacs -Q, using vc-annotate, and
returning to the file, various key inputs like C-f, C-b, and typing characters
have a noticeable delay between key down and screen update. I am using GNOME
45.3 and Wayland.

Steps to reproduce (starting from an empty directory):

$ git init
$ seq 10 > foo
$ git add -A && git commit -m 'c1'
$ seq 10 >> foo
$ git add -A && git commit -m 'c2'
$ seq 10 >> foo
$ git add -A && git commit -m 'c3'
$ emacs -Q

C-x C-f foo RET
C-f C-b ; no noticeable delay
C-x v g
p p n n
C-x k RET
C-f C-b ; noticeable delay

After following those steps, pressing and holding C-f does not visually update
the cursor until 100s of milliseconds later (although occasionally it would
update immediately). However, the cursor would also be updated as soon as C-f
was released. Before running C-x v g, holding C-f would immediately update the
cursor.

Setting the following did not have a noticeable effect:

(setq pgtk-wait-for-event-timeout 0)

After starting a daemon with M-x server-start (from the same emacs as before)
and opening a terminal client with emacsclient -nw, holding down C-f in the foo
buffer immediately updated the cursor, just like in the graphical client before
running C-x v g.

Context:

This delay has been happening to me for a while when using emacs 29 pgtk and
magit. My emacs will start with no key input delay, and then after a while of
editing and doing various magit commands, key inputs would suddenly have the
delay described above after running a particular magit command. The delay would
happen in every buffer. It would persist for the entire life of the emacs
process, even after running desktop-clear, disabling most global minor modes,
closing and re-opening the emacs client window, etc. Like described above,
terminal clients would not have the input lag even when graphical clients did. I
was able to more reliably reproduce this lag when using vc. Although my steps to
reproduce this bug use vc-annotate, I experienced the bug when making commits
with vc as well.

Software information from GNOME settings:
- **Firmware Version:**                            H.F0
- **OS Name:**                                     NixOS 23.11 (Tapir)
- **OS Build:**                                    23.11.20240211.809cca7
- **OS Type:**                                     64-bit
- **GNOME Version:**                               45.3
- **Windowing System:**                            Wayland
- **Kernel Version:**                              Linux 6.1.77

In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.39, cairo version 1.18.0)
Repository revision: 77576cd7626e4a99a5c88aa854091d701edd53a8
Repository branch: master
System Description: NixOS 23.11 (Tapir)

Configured using:
 'configure
 --prefix=/nix/store/yv9dl9jplhk8pgjkkp1qrpp5mw99524r-emacs-pgtk-20240217.0
 --disable-build-details --with-modules --with-pgtk
 --with-native-compilation --with-tree-sitter --with-xwidgets'

Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG JSON
LIBSELINUX LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER
PGTK PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS
TREE_SITTER WEBP XIM XWIDGETS GTK3 ZLIB

Important settings:
  value of $EMACSLOADPATH: 
  value of $EMACSNATIVELOADPATH: 
  value of $LC_MONETARY: en_US.UTF-8
  value of $LC_NUMERIC: en_US.UTF-8
  value of $LC_TIME: en_US.UTF-8
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=fcitx
  locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-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
  minibuffer-regexp-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util text-property-search mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils iso8601 time-date
subr-x help-mode vc-annotate vc vc-git diff-mode easy-mmode
vc-dispatcher cl-loaddefs cl-lib rmc iso-transl tooltip cconv eldoc
paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode
mwheel term/pgtk-win pgtk-win term/common-win pgtk-dnd tool-bar dnd
fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow
isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax
font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine 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 emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads xwidget-internal dbusbind
inotify dynamic-setting system-font-setting font-render-setting cairo
gtk pgtk multi-tty move-toolbar make-network-process native-compile
emacs)

Memory information:
((conses 16 60720 9114) (symbols 48 6128 0) (strings 32 17189 2899)
 (string-bytes 1 599226) (vectors 16 10446)
 (vector-slots 8 145248 6672) (floats 8 36 525) (intervals 56 268 14)
 (buffers 984 12))

bug#69246: 30.0.50; persistent key input delay after using vc commands in pgtk

[Eli Zaretskii]

> Date: Sat, 17 Feb 2024 20:38:06 +0000
> From:  Nick OBrien via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> After opening a file in a git repository with emacs -Q, using vc-annotate, and
> returning to the file, various key inputs like C-f, C-b, and typing characters
> have a noticeable delay between key down and screen update. I am using GNOME
> 45.3 and Wayland.

Did you let vc-annotate enough time to finish, or was it still running
(with "waiting..." shown in the mode line) when you saw those delays?

vc-annotate runs asynchronously, so you cane switch to another buffer,
while the command still runs, and can sometimes slow down the
foreground command.

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]

I followed the steps again and made sure to leave a few seconds after seeing the
"Annotating... done" message before running the next command. After running the
vc commands, I killed the vc-annotate buffer and returned to the foo buffer
(which is in fundamental-mode), and the key input delay still occurs.

On Sunday, February 18th, 2024 at 1:04 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Sat, 17 Feb 2024 20:38:06 +0000
> > From: Nick OBrien via "Bug reports for GNU Emacs,
> > the Swiss army knife of text editors" bug-gnu-emacs@gnu.org
> > 
> > After opening a file in a git repository with emacs -Q, using vc-annotate, and
> > returning to the file, various key inputs like C-f, C-b, and typing characters
> > have a noticeable delay between key down and screen update. I am using GNOME
> > 45.3 and Wayland.
> 
> 
> Did you let vc-annotate enough time to finish, or was it still running
> (with "waiting..." shown in the mode line) when you saw those delays?
> 
> vc-annotate runs asynchronously, so you cane switch to another buffer,
> while the command still runs, and can sometimes slow down the
> foreground command.

bug#69246: 30.0.50; persistent key input delay after using vc commands in pgtk

[Eli Zaretskii]

> Date: Sun, 18 Feb 2024 19:21:48 +0000
> From: Nick OBrien <nick4f42@proton.me>
> Cc: 69246@debbugs.gnu.org
> 
> I followed the steps again and made sure to leave a few seconds after seeing the
> "Annotating... done" message before running the next command. After running the
> vc commands, I killed the vc-annotate buffer and returned to the foo buffer
> (which is in fundamental-mode), and the key input delay still occurs.

Then I suggest to run "M-x profiler-start RET RET", press several keys
that responds with delay, then "M-x profiler-report RET", and post the
full profile after fully expanding it.  That could tell us what is
getting in the way.

FWIW, I tried to reproduce this on my system, but didn't see any
delays.

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]

I ran the profiler twice: once before the input lag started, and once after.
Each time, I ran M-x profiler-start RET RET, repeated C-f C-b for roughly 20
seconds, then ran M-x profiler-stop and M-x profiler-report.

In the foo buffer before running vc-annotate (no noticeable input delay):

          44  63% - command-execute
          44  63%  - byte-code
          44  63%   - read-extended-command
          44  63%    - read-extended-command-1
          44  63%     - completing-read-default
          13  18%        redisplay_internal (C function)
          24  34%   redisplay_internal (C function)
           1   1% - undo-auto--add-boundary
           1   1%    undo-auto--boundaries
           0   0%   ...

In the foo buffer after running vc-annotate, pressing p p n n, and killing the
vc-annotate buffer (noticeable input delay):

          43  72% - command-execute
          42  71%  - byte-code
          42  71%   - read-extended-command
          42  71%    - read-extended-command-1
          42  71%     - completing-read-default
           4   6%        redisplay_internal (C function)
           2   3%      - command-execute
           2   3%         interactive-form
           1   1%  - funcall-interactively
           1   1%     execute-extended-command
          13  22%   redisplay_internal (C function)
           3   5% - timer-event-handler
           3   5%  - apply
           2   3%   - show-paren-function
           1   1%      show-paren--default
           1   1%   - #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_9>
           1   1%      jit-lock-context-fontify
           0   0%   ...

I was able to reproduce the lag on another computer running the same OS (NixOS)
and desktop environment (GNOME with Wayland). I can try to reproduce it with
another linux distribution if that would help.

On Sunday, February 18th, 2024 at 1:31 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> Then I suggest to run "M-x profiler-start RET RET", press several keys
> that responds with delay, then "M-x profiler-report RET", and post the
> full profile after fully expanding it. That could tell us what is
> getting in the way.
> 
> FWIW, I tried to reproduce this on my system, but didn't see any
> delays.

bug#69246: 30.0.50; persistent key input delay after using vc commands in pgtk

[Eli Zaretskii]

> Date: Sun, 18 Feb 2024 20:36:46 +0000
> From: Nick OBrien <nick4f42@proton.me>
> Cc: 69246@debbugs.gnu.org
> 
> I ran the profiler twice: once before the input lag started, and once after.
> Each time, I ran M-x profiler-start RET RET, repeated C-f C-b for roughly 20
> seconds, then ran M-x profiler-stop and M-x profiler-report.
> 
> In the foo buffer before running vc-annotate (no noticeable input delay):
> 
>           44  63% - command-execute
>           44  63%  - byte-code
>           44  63%   - read-extended-command
>           44  63%    - read-extended-command-1
>           44  63%     - completing-read-default
>           13  18%        redisplay_internal (C function)
>           24  34%   redisplay_internal (C function)
>            1   1% - undo-auto--add-boundary
>            1   1%    undo-auto--boundaries
>            0   0%   ...
> 
> In the foo buffer after running vc-annotate, pressing p p n n, and killing the
> vc-annotate buffer (noticeable input delay):
> 
>           43  72% - command-execute
>           42  71%  - byte-code
>           42  71%   - read-extended-command
>           42  71%    - read-extended-command-1
>           42  71%     - completing-read-default
>            4   6%        redisplay_internal (C function)
>            2   3%      - command-execute
>            2   3%         interactive-form
>            1   1%  - funcall-interactively
>            1   1%     execute-extended-command
>           13  22%   redisplay_internal (C function)
>            3   5% - timer-event-handler
>            3   5%  - apply
>            2   3%   - show-paren-function
>            1   1%      show-paren--default
>            1   1%   - #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_9>
>            1   1%      jit-lock-context-fontify
>            0   0%   ...

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.

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]

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

bug#69246: 30.0.50; persistent key input delay after using vc commands in pgtk

[Eli Zaretskii]

> Date: Wed, 21 Feb 2024 02:19:11 +0000
> From: Nick OBrien <nick4f42@proton.me>
> Cc: 69246@debbugs.gnu.org
> 
> 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.

Isn't it expected that the key only appears when it's released?  Po
Lu, any comments to this strange issue?

bug#69246: 30.0.50; persistent key input delay after using vc commands in pgtk

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Wed, 21 Feb 2024 02:19:11 +0000
>> From: Nick OBrien <nick4f42@proton.me>
>> Cc: 69246@debbugs.gnu.org
>> 
>> 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.
>
> Isn't it expected that the key only appears when it's released?  Po
> Lu, any comments to this strange issue?

Do other GTK 3 programs exhibit this lengthening of the intervals
between generated repeat keypresses?  What if the environment variable
GTK_IM_MODULE is set to `none'?

TIA.

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]

On Wednesday, February 21st, 2024 at 6:41 AM, Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Wed, 21 Feb 2024 02:19:11 +0000
> > From: Nick OBrien nick4f42@proton.me
> > Cc: 69246@debbugs.gnu.org
> > 
> > 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.
> 
> 
> Isn't it expected that the key only appears when it's released? Po
> Lu, any comments to this strange issue?

I would think it's expected for the key to appear after pressing the key, not
releasing it.


On Wednesday, February 21st, 2024 at 6:49 AM, Po Lu <luangruo@yahoo.com> wrote:

> Do other GTK 3 programs exhibit this lengthening of the intervals
> between generated repeat keypresses? What if the environment variable
> GTK_IM_MODULE is set to `none'?
> 
> TIA.

Running "GTK_IM_MODULE=none emacs -Q" and following the steps in the original
bug report, the lag appears to be fixed. I reproduced it three times, and each
time there was no lag. For reference, I tried again with GTK_IM_MODULE=fcitx
(how it was in the original bug report) and 4/4 times I experienced the lag.

I haven't ever experienced this sort of lag in Firefox or signal-desktop, two
gtk3 apps I regularly use. And just to clarify, the lag doesn't seem to lengthen
the interval between generated repeat key-presses. The repeated key-presses just
seem /choppier/, as if the frame-rate is lower. The lag is most obvious when
holding down a key and releasing after a single key appears.

I'll try using my normal config with GTK_IM_MODULE=none and see if I experience
the lag in everyday use.

Thanks

bug#69246: 30.0.50; persistent key input delay after using vc commands in pgtk

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Nick OBrien <nick4f42@proton.me> writes:

> Running "GTK_IM_MODULE=none emacs -Q" and following the steps in the original
> bug report, the lag appears to be fixed. I reproduced it three times, and each
> time there was no lag. For reference, I tried again with GTK_IM_MODULE=fcitx
> (how it was in the original bug report) and 4/4 times I experienced the lag.
>
> I haven't ever experienced this sort of lag in Firefox or signal-desktop, two
> gtk3 apps I regularly use. And just to clarify, the lag doesn't seem to lengthen
> the interval between generated repeat key-presses. The repeated key-presses just
> seem /choppier/, as if the frame-rate is lower. The lag is most obvious when
> holding down a key and releasing after a single key appears.
>
> I'll try using my normal config with GTK_IM_MODULE=none and see if I experience
> the lag in everyday use.

I suppose your problem is that fcitx cannot tolerate programs responding
to keyboard input in a manner unconventional for a GTK program, as Emacs
does.

bug#69246: 30.0.50; persistent key input delay after using vc commands in pgtk

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  69246@debbugs.gnu.org
> Date: Thu, 22 Feb 2024 09:20:11 +0800
> 
> Nick OBrien <nick4f42@proton.me> writes:
> 
> > Running "GTK_IM_MODULE=none emacs -Q" and following the steps in the original
> > bug report, the lag appears to be fixed. I reproduced it three times, and each
> > time there was no lag. For reference, I tried again with GTK_IM_MODULE=fcitx
> > (how it was in the original bug report) and 4/4 times I experienced the lag.
> >
> > I haven't ever experienced this sort of lag in Firefox or signal-desktop, two
> > gtk3 apps I regularly use. And just to clarify, the lag doesn't seem to lengthen
> > the interval between generated repeat key-presses. The repeated key-presses just
> > seem /choppier/, as if the frame-rate is lower. The lag is most obvious when
> > holding down a key and releasing after a single key appears.
> >
> > I'll try using my normal config with GTK_IM_MODULE=none and see if I experience
> > the lag in everyday use.
> 
> I suppose your problem is that fcitx cannot tolerate programs responding
> to keyboard input in a manner unconventional for a GTK program, as Emacs
> does.

What is the "unconventional manner" in which GTK Emacs responds to
keyboard input?  And why do we do that?

bug#69246: 30.0.50; persistent key input delay after using vc commands in pgtk

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> What is the "unconventional manner" in which GTK Emacs responds to
> keyboard input?  And why do we do that?

Emacs doesn't receive ASCII keyboard input as strings delivered by the
input method, but as unprocessed key events with metadata such as active
modifier masks, timestamps and keycodes, which is self-explanatory.

bug#69246: 30.0.50; persistent key input delay after using vc commands in pgtk

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: nick4f42@proton.me,  69246@debbugs.gnu.org
> Date: Thu, 22 Feb 2024 16:02:20 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > What is the "unconventional manner" in which GTK Emacs responds to
> > keyboard input?  And why do we do that?
> 
> Emacs doesn't receive ASCII keyboard input as strings delivered by the
> input method, but as unprocessed key events with metadata such as active
> modifier masks, timestamps and keycodes, which is self-explanatory.

Thanks, but it seems like something was left out of this description:
you started by saying that Emacs _responds_ to keyboard input in some
unexpected way, but here you are talking about how Emacs _receives_
keyboard input, and say nothing about how we _respond_ to it.  Why
would GTK care how Emacs _receives_ input if we don't tell it back
something about that input?

bug#69246: 30.0.50; persistent key input delay after using vc commands in pgtk

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> Thanks, but it seems like something was left out of this description:
> you started by saying that Emacs _responds_ to keyboard input in some
> unexpected way, but here you are talking about how Emacs _receives_
> keyboard input, and say nothing about how we _respond_ to it.  Why
> would GTK care how Emacs _receives_ input if we don't tell it back
> something about that input?

I meant that the GTK toolkit communicates with the input method upon
receiving a key event, and the details of this communication vary by
whether the program using the toolkit registers for key events or for
text.  Because most GTK programs that expect text input take the latter
approach, it's not altogether surprising that recent input methods,
being designed for the same, come into conflict with Emacs's
unconventional behavior.

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]

A few updates:

- After using my normal emacs config with GTK_IM_MODULE=none for a few
  days, I did not encounter the input lag. When previously using
  GTK_IM_MODULE=fcitx, I would have encountered the lag multiple times
  during the same pattern of use.

- I tried installing ibus and following the steps in the original bug
  report with GTK_IM_MODULE=ibus. I encountered the same lag I did with
  fcitx.

bug#69246: 30.0.50; persistent key input delay after using vc commands in pgtk

[Eli Zaretskii]

> Date: Sat, 24 Feb 2024 22:24:04 +0000
> From: Nick OBrien <nick4f42@proton.me>
> Cc: 69246@debbugs.gnu.org
> 
> A few updates:
> 
> - After using my normal emacs config with GTK_IM_MODULE=none for a few
>   days, I did not encounter the input lag. When previously using
>   GTK_IM_MODULE=fcitx, I would have encountered the lag multiple times
>   during the same pattern of use.
> 
> - I tried installing ibus and following the steps in the original bug
>   report with GTK_IM_MODULE=ibus. I encountered the same lag I did with
>   fcitx.

Thanks for getting back to us.  AFAIU, this is a more-or-less general
problem, which happens with many GTK input methods, perhaps all of
them.  We now have an entry in PROBLEMS about this.