[vim/vim] GTK4: Fix find replace dialog (PR #20613)
Foxe Chen
Used Claude to find out what was missing in GTK4 compared to GTK3:
-
SharedFindReplace struct — missing button pointer fields
GTK3 has 10 fields: dialog, wword, mcase, up, down, what, with, find, replace, all.
GTK4 has 7: dialog, what, with, wword, mcase, up, down — find, replace, and all are gone.
This is the structural root cause of most of the other missing behaviours below, since there's nothing to reference for sensitivity updates or default focus. -
No dynamic button sensitivity (entry_changed_cb missing entirely)
GTK3 connects a "changed" signal on frdp->what to entry_changed_cb, which enables/disables Find Next, Replace, and Replace All whenever the entry text changes. GTK4 sets the initial sensitivity once from entry_text and never updates it. Because the button pointers aren't stored in the struct either, you couldn't even add a callback later without also fixing issue 1. -
No find_key_press_event on the entry widgets
GTK3 connects find_key_press_event (via g_signal_connect_after) to both frdp->what and frdp->with. This handler does two things:
Pressing inside either entry hides the dialog
Ctrl/Shift key combinations are passed through to prevent intercepting normal selection shortcuts
GTK4 connects no key handler to the entries. inside the "Find what" or "Replace with" field does nothing — you must click Close. -
Wrong behaviour in replace mode — frdp->what activate
GTK3 replace mode: frdp->what activate → entry_activate_cb → gtk_widget_grab_focus(frdp->with) — focus moves to the replacement field, matching the expected workflow of typing a search term, hitting Enter, then typing the replacement.
GTK4 replace mode: frdp->what activate → find_replace_cb(FRD_R_FINDNEXT) — it immediately triggers a search instead of moving focus. The replacement field is never reached by keyboard alone. -
in frdp->with does nothing in GTK4
GTK3 connects "activate" on frdp->with to find_replace_cb(FRD_R_FINDNEXT), so pressing Enter after typing the replacement text triggers Find Next.
GTK4 connects no "activate" signal on frdp->with at all. Enter in that field is a dead key. -
No default button (gtk_widget_grab_default missing)
GTK3 calls gtk_widget_grab_default(frdp->find) so that Find Next is the dialog's default widget — activated by anywhere in the dialog when no entry has focus. GTK4 never sets a default widget on the window. -
Re-raise path missing focus logic for frdp->with
GTK3, when re-raising an existing dialog in replace mode, checks entry_get_text_length(frdp->what) > 0 and focuses frdp->with if there's already a search term. GTK4 always focuses frdp->what unconditionally in the re-raise early-return path — the frdp->with focus grab that exists in the code is unreachable from the re-raise branch (it's below the return). -
Dialog lifecycle — hide vs. destroy
GTK3: Close button calls gtk_widget_hide, delete-event calls gtk_widget_hide_on_delete. The dialog widget is kept alive forever after first creation, so its window position is preserved between uses.
GTK4: Close button calls gtk_window_destroy, and dialog_destroyed_cb sets frdp->dialog = NULL. The dialog is fully torn down each close. Next invocation creates a fresh one centred on screen.
You can view, comment on, or merge this pull request online at:
https://github.com/vim/vim/pull/20613
Commit Summary
- 167f008 fix find replace dialog for gtk4 gui
File Changes
(1 file)
- M src/gui_gtk4.c (115)
Patch Links:
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#20613)thanks
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#20613)Something is wrong here. The dialog loses the decorations after the second invocation:
image.png (view on web)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
Foxe Chen
64-bitman left a comment (vim/vim#20613)Something is wrong here. The dialog loses the decorations after the first invocation:
I cannot reproduce, If you are using WSLg I'm guessing thats just a bug with it.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#20613)not using WSL, a debian inside a hyper-v using Wayland.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
Foxe Chen
64-bitman left a comment (vim/vim#20613)not using WSL, a debian inside a hyper-v using Wayland.
You need to press Escape to discard the dialog:
Screen.Recording.2026-06-23.211827.mp4
Should be fixed now
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.