[vim/vim] GTK4 can't input text using an input method and preedit on (Issue #20257)
依云
lilydjwg created an issue (vim/vim#20257)Steps to reproduce
- Run
vim -g --clean - Try to use an input method (e.g. fcitx5) to type something. Note that fcitx5 by default disables preedit string for GVim because of this kind of bugs. Press
Ctrl-Alt-pto toggle it on if not. - The input method appears for a brief moment and disappears. Text can't be inputted.
Expected behaviour
GVim recognizes an input method is composing text and displays the preedit text underlined, not cancels the input.
The input method window's location is also wrong, but seems to be the GTK bug.
Version of Vim
9.2.491
Environment
Arch Linux GTK 4 GUI, Wayfire Wayland compositor.
Logs and stack traces
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
mattn
mattn left a comment (vim/vim#20257)I think this might fix it — could you try the following patch?
diff --git a/src/gui_gtk4.c b/src/gui_gtk4.c index 24ad6ddce2..a64a68f780 100644 --- a/src/gui_gtk4.c +++ b/src/gui_gtk4.c @@ -1835,6 +1835,8 @@ drawarea_realize_cb(GtkWidget *widget UNUSED, gpointer data UNUSED) #ifdef FEAT_XIM xim_init(); + if (gui.in_focus) + xim_set_focus(TRUE); #endif }
When the drawing area is realized after the window has already been focused (which is the usual case at startup), xim_init() creates the GtkIMContext, but no further focus signal fires — so gtk_im_context_focus_in() is never called on the new context. That matches what you're seeing: fcitx5 starts a session and immediately drops it because the client hasn't actually focused-in.
The above tells xim to pick up the existing focus state right after init.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
依云
lilydjwg left a comment (vim/vim#20257)No, it doesn't work. Nothing has changed. I suppose this line relates to XIM? But I'm using Wayland.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
mattn
mattn left a comment (vim/vim#20257)I opened #20266 which I believe fixes this. Could you try it and let me know if the input method works correctly for you?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
依云
lilydjwg left a comment (vim/vim#20257)It doesn't work either. I think the issue is not with key events (it reaches the input method), but with preedit string handling.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
mattn
mattn left a comment (vim/vim#20257)Thanks for testing. On my side I verified the fix on Ubuntu with mozc/ibus, and preedit works correctly there. Could you share more details about your environment — which input method framework and engine are you using (fcitx5 with what engine?)? That will help me reproduce the preedit issue you're seeing.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
依云
lilydjwg left a comment (vim/vim#20257)I'm using the Wubi input method, provided by the libtable.so engine, from fcitx5-chinese-addons. But it is producible with other engines, e.g. pinyin, mozc, even the quickphrase feature. Whenever a preedit string is about to show up, it disappears with the input method window, like a IM context reset. GVim exits the -- IM INSERT -- mode as soon as it enters it.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
mattn
mattn left a comment (vim/vim#20257)Thanks for the details. I have a hypothesis: on Wayland with fcitx5, when the IM popup/candidate window appears, focus may leave the drawing area, which fires our focus controller's leave signal. That calls gtk_im_context_focus_out() on the IM context and cancels the preedit session — which matches what you're seeing.
ibus on Wayland likely doesn't trigger a focus-leave on the client because its preedit/candidate UI is composited differently, which would explain why I can't reproduce this with mozc/ibus.
Could you test with the focus_out path neutralized? Apply this on top of #20266 and try again:
diff --git a/src/gui_gtk4.c b/src/gui_gtk4.c --- a/src/gui_gtk4.c +++ b/src/gui_gtk4.c @@ -1796,9 +1796,7 @@ static void focus_out_event(GtkEventControllerFocus *controller UNUSED, gpointer data UNUSED) { - gui_focus_change(FALSE); - if (blink_state != BLINK_NONE) - gui_mch_stop_blink(TRUE); + // temporarily disabled to test IM preedit issue }
If the preedit stays alive with that patch, the focus-leave path is the culprit and I'll work out a proper fix (e.g. only treat the toplevel window's focus state as the real focus, not the drawing area's).
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
依云
lilydjwg left a comment (vim/vim#20257)The patch doesn't work.
on Wayland with fcitx5, when the IM popup/candidate window appears, focus may leave the drawing area, which fires our focus controller's
leavesignal.
This should not happen.
I ran with WAYLAND_DEBUG=1 and discovered that, there are two surfaces, #42 and #78 in the log. Keyboard focus started on #42, and when preedit string arrives, it transfers to #78 and back soon. It seems that GVim tries to draw the preedit string on a popup and caused a focus change.
[1735454.959] {Default Queue} zwp_text_input_v3#58.preedit_string("人", 0, 0)
[1735454.972] {Default Queue} zwp_text_input_v3#58.done(2)
[1735462.404] {Default Queue} -> wl_compositor#8.create_surface(new id wl_surface#78)
[1735462.416] {Default Queue} -> wp_fractional_scale_manager_v1#25.get_fractional_scale(new id wp_fractional_scale_v1#79, wl_surface#78)
[1735462.422] {Default Queue} -> wp_viewporter#20.get_viewport(new id wp_viewport#77, wl_surface#78)
[1735464.897] {mesa vk display queue} -> zwp_linux_dmabuf_v1#54.get_surface_feedback(new id zwp_linux_dmabuf_feedback_v1#66, wl_surface#78)
[1735465.143] {Default Queue} -> org_kde_kwin_server_decoration_manager#17.create(new id org_kde_kwin_server_decoration#86, wl_surface#78)
[1735465.148] {Default Queue} -> org_kde_kwin_server_decoration#86.request_mode(2)
[1735465.193] {Default Queue} -> xdg_wm_base#38.get_xdg_surface(new id xdg_surface#87, wl_surface#78)
[1735465.197] -> xdg_surface#87.get_toplevel(new id xdg_toplevel#88)
[1735465.201] -> xdg_toplevel#88.set_parent(xdg_toplevel#64)
[1735465.203] -> xdg_toplevel#88.set_title("gvim")
[1735465.206] -> xdg_toplevel#88.set_app_id("gvim")
[1735465.209] -> wl_surface#78.commit()
[1735465.264] {Default Queue} -> zwp_text_input_v3#58.set_content_type(0, 0)
[1735465.307] {Default Queue} -> zwp_text_input_v3#58.set_cursor_rectangle(0, 65, 0, 0)
[1735465.311] {Default Queue} -> zwp_text_input_v3#58.commit()
[1735467.140] -> wl_surface#42.frame(new id wl_callback#89)
[1735467.156] {Default Queue} -> wp_presentation#19.feedback(wl_surface#42, new id wp_presentation_feedback#90)
[1735467.161] -> wl_surface#42.offset(0, 0)
[1735467.236] {mesa vk display queue} -> wl_surface#42.attach(wl_buffer#72, 0, 0)
[1735467.240] {mesa vk display queue} -> wl_surface#42.damage_buffer(0, 65, 816, 487)
[1735467.242] {mesa vk display queue} -> wl_surface#42.commit()
[1735468.834] -> wl_surface#78.set_opaque_region(wl_region#100)
[1735468.845] -> wl_surface#78.frame(new id wl_callback#101)
[1735468.849] {Default Queue} -> wp_presentation#19.feedback(wl_surface#78, new id wp_presentation_feedback#102)
[1735468.852] -> wl_surface#78.offset(0, 0)
[1735468.898] {mesa vk display queue} -> wl_surface#78.attach(wl_buffer#93, 0, 0)
[1735468.902] {mesa vk display queue} -> wl_surface#78.damage_buffer(0, 0, 13, 23)
[1735468.905] {mesa vk display queue} -> wl_surface#78.commit()
[1735469.695] {Default Queue} wl_keyboard#41.leave(353029, wl_surface#42)
[1735469.703] {Default Queue} wl_keyboard#41.enter(353030, wl_surface#78, array[4])
[1735469.708] {Default Queue} wl_keyboard#41.modifiers(353031, 0, 0, 0, 0)
[1735469.725] {Default Queue} wl_data_device#33.data_offer(new id wl_data_offer#4278190082)
...
[1735469.842] {Default Queue} zwp_text_input_v3#58.leave(wl_surface#42)
[1735469.845] {Default Queue} -> zwp_text_input_v3#58.disable()
[1735469.851] {Default Queue} -> zwp_text_input_v3#58.commit()
[1735469.887] -> xdg_toplevel#88.destroy()
[1735469.893] -> xdg_surface#87.destroy()
[1735469.898] -> wl_surface#78.attach(nil, 0, 0)
[1735469.901] -> wl_surface#78.commit()
[1735470.458] {Default Queue} zwp_text_input_v3#58.enter(wl_surface#78)
[1735470.472] {Default Queue} -> zwp_text_input_v3#58.enable()
[1735470.485] {Default Queue} -> zwp_text_input_v3#58.set_content_type(0, 0)
[1735470.496] {Default Queue} -> zwp_text_input_v3#58.set_cursor_rectangle(0, 65, 0, 0)
[1735470.510] {Default Queue} -> zwp_text_input_v3#58.commit()
[1735470.513] {Default Queue} wp_fractional_scale_v1#79.preferred_scale(120)
[1735470.517] discarded xdg_toplevel#88.configure(0, 0, array[4])
[1735470.521] discarded xdg_surface#87.configure(353028)
[1735470.523] wl_surface#78.enter(wl_output#28)
[1735470.543] wl_surface#78.preferred_buffer_scale(1)
[1735470.547] xdg_toplevel#64.configure(0, 0, array[0])
[1735470.550] xdg_surface#63.configure(353027)
[1735471.751] -> xdg_surface#63.ack_configure(353027)
[1735471.785] {Default Queue} -> zwp_text_input_v3#58.disable()
[1735471.789] {Default Queue} -> zwp_text_input_v3#58.commit()
[1735471.869] {Default Queue} wl_keyboard#41.leave(353033, wl_surface#78)
[1735471.876] {Default Queue} wl_keyboard#41.enter(353034, wl_surface#42, array[4])
...
[1735471.987] {Default Queue} zwp_text_input_v3#58.leave(wl_surface#78)
[1735471.989] {Default Queue} zwp_text_input_v3#58.enter(wl_surface#42)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
mattn
mattn left a comment (vim/vim#20257)Found the root cause. The trigger was the preedit window we were creating ourselves — that toplevel competed with the drawing area for Wayland keyboard focus, which caused zwp_text_input_v3.disable() and tore down the IM session, cancelling the preedit. On Wayland-based GTK4 we should not create our own preedit window; the IM (fcitx5 etc.) already draws the preedit at the cursor location reported via gtk_im_context_set_cursor_location(), so leaving the rendering to it is the right thing.
I've pushed an additional commit to #20266 that makes im_preedit_window_open()/im_preedit_window_close() no-ops on GTK4. Could you give it another try?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
依云
lilydjwg left a comment (vim/vim#20257)It becomes significantly better: inputting works, and the popup follows the cursor more closely. The only left issue is that the preedit string appears nowhere.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
mattn
mattn left a comment (vim/vim#20257)Good progress, thanks! Could you try :set imstyle=0 (or add set imstyle=0 to your vimrc) and see if the preedit shows up inline in the buffer?
Background: 'imstyle' selects how Vim handles the preedit string. The default 1 (over-the-spot) was meant for the popup window we just removed, so on GTK4 it currently shows nothing. 0 (on-the-spot) makes Vim insert the preedit text inline as it's being composed, which is what fcitx5/text-input-v3 expects when the IM sends preedit_string to the client.
If that works for you we'll consider flipping the default to 0 on GTK4 builds.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
mattn
mattn left a comment (vim/vim#20257)A bit more investigation. Looks like on GTK4/Wayland, over-the-spot is no longer supported by the platform — only on-the-spot is available:
- The
zwp_text_input_v3::preedit_stringevent in Wayland's text-input-v3 protocol requires the client to insert the preedit at the cursor position; there's no mechanism for the IM to draw a preedit popup itself. - GTK4's
gtk_im_context_set_use_preedit()defaults toTRUE(deliver preedit signals to the app), andGTK_WINDOW_POPUPis gone in GTK4 (migration guide), so the kind of borderless preedit window Vim used to build for over-the-spot can no longer be created.
So on GTK4 we'll probably have to fix 'imstyle' to 0 (on-the-spot) regardless of the user setting — over-the-spot has nothing to render with anymore. I'll prepare that change. In the meantime, could you confirm that :set imstyle=0 makes the preedit show up inline for you?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
mattn
mattn left a comment (vim/vim#20257)After a deeper look, GTK4's gtk_im_context_set_use_preedit() actually controls the Wayland ZWP_TEXT_INPUT_V3_CONTENT_HINT_PREEDIT_SHOWN content hint — when it's FALSE the hint is dropped and IMs like fcitx5 can fall back to drawing the preedit in their own floating window. So both styles are usable on GTK4, just via different mechanisms.
I've added a commit to #20266 that wires 'imstyle' to that hint:
:set imstyle=0(on-the-spot): the hint is set, fcitx5 sends preedit to the client, Vim renders it inline at the cursor.:set imstyle=1(over-the-spot, the GTK build default): the hint is dropped, fcitx5 shows its own preedit window.
Could you try both and let me know which works in your setup? On Wayland with fcitx5 + GTK4 I expect imstyle=0 to be the smoother path, but imstyle=1 should now also be a viable choice if you prefer fcitx5's own UI.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
mattn
mattn left a comment (vim/vim#20257)When the preedit window was implemented as a GtkWindow created with gtk_new_window(), Wayland treated it as a new xdg_toplevel and moved keyboard focus there as soon as preediting started. That tore down the text-input-v3 session and caused the reported issue. Re-implementing the preedit window with GtkPopover (xdg_popup) should avoid the problem, since a popup is a child of its parent surface and does not move keyboard focus.
The branch is at https://github.com/mattn/vim/tree/gtk4-im-input (PR #20266). Please give it a try with both :set imstyle=0 and :set imstyle=1.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
依云
lilydjwg left a comment (vim/vim#20257)imstyle=0 works.
With the new code imstyle=1 also works, but there is a little misalignment:
The cursor is also blinking at the left top corner of "中" character. It seems to happen because the popup doesn't fully cover the place.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
mattn
mattn left a comment (vim/vim#20257)@lilydjwg I've pushed an additional commit to #20266 that addresses the cursor-bleed-through with imstyle=1:
gtk_popover_set_position(GTK_POS_BOTTOM)is now set explicitly withanchor.h == 0, so the popover's top edge lands exactly onFILL_Y(row)instead of relying on GtkPopover's auto-flip from the defaultGTK_POS_TOP.- The popover frame is painted with
gui.back_pixel(via a CSS provider rebuilt only when the background colour changes) instead of being transparent. This makes the popover surface fully cover the cursor cell so the blinking cursor no longer shows through.
Could you pull the latest gtk4-im-input branch (https://github.com/mattn/vim/tree/gtk4-im-input) and check whether the misalignment / cursor blink at the top-left of "中" is gone with :set imstyle=1? imstyle=0 should also continue to work as before.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
依云
lilydjwg left a comment (vim/vim#20257)It doesn't seem to make a difference:
default.png (view on web)Also, the following warning may be printed on exiting when preedit string is still shown:
(gvim:130778): Gtk-WARNING **: 16:14:13.440: Finalizing 0\xb4\xf0\x89?V 0x563f89c42fc0, but it still has children left:
- GtkPopover 0x563f8ac70f90
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
mattn
mattn left a comment (vim/vim#20257)Thanks for testing. Looking at the new screenshot, the popover for "中文" looks horizontally offset to the right of where the cursor cell should be — there's a visible gap between "好" and "中", and what looks like a thin vertical mark in that gap. That suggests my hypothesis (cursor showing through a transparent popover frame) was wrong; the popover surface itself seems to be placed a few pixels to the right of the cursor cell.
To make sure I'm interpreting the screenshot correctly, could you confirm a couple of things?
- Is the small vertical mark between "好" and "中" the blinking text cursor? Or is it something else (e.g. part of the preedit underline)?
- Roughly how big is the horizontal gap — about a half-cell, a full cell, or just a few pixels?
- Is "中文" vertically aligned with "你好", or is it raised/lowered as in the first screenshot?
- Does the offset change at all if you put the cursor on a different column (e.g. middle of the line instead of right after "你好")? This would tell us if it's a fixed offset or scales with column.
For the Finalizing ... but it still has children left warning — does it print every time you exit with preedit active, or only sometimes? I'll look into it separately; im_shutdown() already does gtk_widget_unparent(preedit_window) so the order with mainwin teardown may need adjusting.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
依云
lilydjwg left a comment (vim/vim#20257)
- Where in "the left top corner of '中' character" does it appear visually?
The black dot.
Is "中文" vertically aligned with "你好", or is it raised/lowered?
It is lower.
If possible, could you also share a short screen recording of
imstyle=1in action? A still frame only captures one moment, so a recording would help me see what's actually happening as you compose. No worries if it's inconvenient — the answers above are enough.
https://github.com/user-attachments/assets/c571c7d6-0f5a-46c1-a1d3-cdb00f52b8bb
For the
Finalizing ... but it still has children leftwarning — does it print every time you exit with preedit active, or only sometimes? I'll look into it separately.
Every time. This is not a frequent issue for me however, because usually I exit GVim without the input method active.
Detail: I use ZZ or ZQ to exit Vim, and when the input method is active (e.g. because my fcitx.vim plugin didn't work for whatever reason), it enters Quick Phrase mode, and these keys are shown in the preedit string until I press Enter to commit them, and Vim then exits.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
mattn
mattn left a comment (vim/vim#20257)I dug into this further with printf instrumentation in our preedit-changed handler and found something significant:
- With ibus,
imstyle=0andimstyle=1both work correctly — the handler fires and Vim renders the preedit popover at the cursor cell. - With fcitx5,
imstyle=0works, butimstyle=1is not supported by the IM in the way Vim expects — the preedit-changed signal never reaches Vim, so we have no way to know when composing starts or what the preedit text is, and Vim cannot render the preedit popover at the cursor cell. - The preedit display you see one line below the cursor with fcitx5 is fcitx5's own preedit window, positioned by fcitx5 relative to the cursor rectangle. Vim has no control over its position.
- GtkIMContext abstracts away which IM backend is in use, so Vim cannot detect "this is fcitx5" and adjust behavior accordingly.
So with fcitx5 on GTK4, you have two options:
- Use
:set imstyle=0, which makes Vim render the preedit inline at the cursor (this works in your setup as you've already confirmed). - Keep
:set imstyle=1and accept that the preedit will appear in fcitx5's own window rather than overlapping the cursor cell in Vim — Vim cannot draw the preedit at the cursor cell when fcitx5 is the IM.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
mattn
mattn left a comment (vim/vim#20257)@chrisbra given the findings above, this looks like a documentation problem rather than a code problem. Could you advise on how to phrase it?
Two things should probably be noted under 'imstyle':
-
imstyle=1is silently inoperative with fcitx5. fcitx5 never delivers thepreedit-changedsignal to GTK clients (verified by instrumenting our handler — it fires for ibus but never for fcitx5), so Vim has no way to know composing has started or what the preedit text is. The preedit display the user then sees comes entirely from fcitx5's own window. There is no Vim-side workaround becauseGtkIMContextabstracts the backend away. -
imstyle=0has observable side effects during composition. The preedit text is fed through Vim's normal input path, so:InsertCharPrefires for each preedit character (and each character of each re-insertion when the preedit string changes).- Buffer change listeners registered via
listener_add()fire on every preedit change. - The
'.mark moves while composing. - (The
'modified'flag andTextChangedIare protected — they only fire on commit, not during composition.)
Would you like me to prepare a doc-only patch covering both, or do you have a preferred wording / scope?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
依云
lilydjwg left a comment (vim/vim#20257)The preedit display you see one line below the cursor with fcitx5 is fcitx5's own preedit window, positioned by fcitx5 relative to the cursor rectangle. Vim has no control over its position.
This is in contradiction with my understanding on Wayland input method protocols. I can investigate further later when I have time.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.