Add GTK4 GUI backend using separate source files instead of adding conditional branches to the existing GTK2/GTK3 code. GTK4's API changes are too fundamental for #if branching to be maintainable.
This PR was developed with the assistance of Claude Code (Anthropic).
./configure --enable-gui=gtk4
make
Requires GTK 4.10+ (for GtkFontDialog).
gui_gtk4_f.c/h — GtkForm widget (extends GtkWidget, uses GskTransform)gui_gtk4_x11.c — Main GUI implementation (events, drawing, fonts, colors)gui_gtk4.c — Scrollbars, dialogs, menu stubs:set guifont=*) via GtkFontDialog:q! exit:browse)gui_mch_dialog)gui_mch_delete_lines / gui_mch_insert_lines)This is a work in progress.
https://github.com/vim/vim/pull/19815
(36 files)
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@mattn pushed 1 commit.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@mattn pushed 1 commit.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@mattn pushed 1 commit.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@mattn pushed 1 commit.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@mattn pushed 1 commit.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@mattn pushed 1 commit.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@mattn pushed 1 commit.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@mattn pushed 1 commit.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@mattn pushed 1 commit.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@mattn pushed 1 commit.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@mattn pushed 1 commit.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@mattn pushed 1 commit.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@mattn pushed 1 commit.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
wow, very nice. Can you share a screenshot of vim --clean -g ?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
I think the GTK4 port of GVim should focus more on Wayland instead of X11, which is already deprecated and will be removed in GTK5. I suppose there are issues with keyboard layout detection, but there a much more users that have it working fine. Having a 2800 line file called "gui_gtk4_x11.c" does not feel right...
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
Default GDK backend is x11
image.png (view on web) image.png (view on web) image.png (view on web) image.png (view on web)$ GDK_BACKEND=wayland GSK_RENDERER=cairo ./vim -gf
image.png (view on web)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
@mattn pushed 1 commit.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
Currently the only X11 dependency in the GTK4 backend is XParseGeometry from <X11/Xutil.h>. By implementing our own geometry parser, we can remove the X11 dependency entirely and switch the default GDK_BACKEND to Wayland.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
This also means we could rename gui_gtk4_x11.c to gui_gtk4.c since it would no longer have any X11 dependency.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
@mattn pushed 1 commit.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@mattn pushed 1 commit.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@mattn pushed 1 commit.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@mattn pushed 1 commit.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@mattn pushed 1 commit.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@mattn pushed 1 commit.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@mattn pushed 1 commit.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@mattn pushed 1 commit.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
The GTK4 port now has zero direct X11 dependency 💪
$ nm -u ./vim | grep -i '^.\+U.*X[A-Z]' | grep -v 'gdk\|gtk\|glib\|pango\|cairo\|GLIBC\|g_\|getx'
(no output)
The X11 libraries shown by ldd are all indirect dependencies pulled in by libgtk-4.so itself, not by Vim's code.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
@mattn pushed 1 commit.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
Multi-byte characters are now rendering correctly. Getting close to completion.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
I am getting build errors when trying to compile this PR. It seems that multiple functions in gui_gtk4.c are not exposed in the .pro file
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
@mattn pushed 1 commit.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
Sorry, the proto file was broken when gui_gtk4_x11.c was merged into gui_gtk4.c. It should be fixed now.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
@mattn pushed 1 commit.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
Here are some compilation errors I am getting on Linux:
getchar.c: In function ‘vgetc’:
getchar.c:2023:44: error: passing argument 1 of ‘gtk_menu_shell_select_first’ makes pointer from integer without a cast [-Wint-conversion]
2023 | GTK_MENU_SHELL(gui.menubar), FALSE);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
| |
| GType {aka long unsigned int}
In file included from proto.h:306,
from vim.h:2525,
from getchar.c:15:
proto/gui_gtk4.pro:90:40: note: expected ‘void *’ but argument is of type ‘GType’ {aka ‘long unsigned int’}
90 | void gtk_menu_shell_select_first(void *shell, gboolean sr);
| ~~~~~~^~~~~
optionstr.c: In function ‘expand_set_guifont’:
optionstr.c:2680:19: error: passing argument 2 of ‘expand_set_opt_callback’ from incompatible pointer type [-Wincompatible-pointer-types]
2680 | args, gui_mch_expand_font, &wide, numMatches, matches);
| ^~~~~~~~~~~~~~~~~~~
| |
| int (*)(optexpand_T *, int *, char_u ***) {aka int (*)(optexpand_T *, int *, unsigned char ***)}
optionstr.c:960:16: note: expected ‘void (*)(optexpand_T *, void *, int (*)(char_u *))’ {aka ‘void (*)(optexpand_T *, void *, int (*)(unsigned char *))’} but argument is of type ‘int (*)(optexpand_T *, int *, char_u ***)’ {aka ‘int (*)(optexpand_T *, int *, unsigned char ***)’}
960 | void (*func)(optexpand_T *, void* params, int (*cb)(char_u *val)),
| ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from proto.h:306,
from vim.h:2525,
from optionstr.c:14:
proto/gui_gtk4.pro:32:5: note: ‘gui_mch_expand_font’ declared here
32 | int gui_mch_expand_font(optexpand_T *args, int *numMatches, char_u ***matches);
| ^~~~~~~~~~~~~~~~~~~
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
@mattn pushed 1 commit.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@mattn pushed 1 commit.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@mattn pushed 1 commit.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@mattn pushed 1 commit.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@mattn pushed 1 commit.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@mattn pushed 1 commit.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
I build w/ gtk4 overtime, but may it makes no sense until this gets merge. Thx for your work @mattn
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
Thank @mattn this looks very interesting! :)
(GNU/Linux dwm x11)
This is a screenshot with the black version with set guioptions+=d
vim-gtk4.png (view on web)I understand that this still in beta fase, For now I was able to build it without problems, but I can only start it using gvim --nofork (without --nofork, does not start).
Thanks again and I hope that this will be merged when ready!
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
@mattn pushed 1 commit.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
Since I'm developing this on WSL2, I haven't been able to test the Broadway backend yet. If you have a native Linux environment, you should be able to run gvim in a browser:
broadwayd :5GDK_BACKEND=broadway BROADWAY_DISPLAY=:5 ./vim -gfYou should see gvim running inside the browser. I'd appreciate it if someone could give it a try!
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
@mattn pushed 1 commit.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
Hello,
I can't really test it properly, but following the recent GTK4 updates, the --nofork issue is now resolved and it's not needed anymore, starts well by default now.
Small things that I quickly detect when use it:
When running in an X11 environment, the WM_CLASS attribute is empty. This prevents window managers (I use dwm) from correctly identifying the application, applying window rules, or displaying the correct icon.
Command: xprop
Output: WM_CLASS(STRING) = "", ""
(gtk2, gtk3) already has this by default.
Expected: WM_CLASS(STRING) = "gvim", "Gvim"
Setting the k flag (Keep window size) in guioptions causes an immediate crash.
Steps to reproduce:
Start gvim: gvim --clean
Run: :set guioptions=k
Result: Segmented fault / Crash.
Even with a supported font and the guiligatures option set, symbols are not displayed as expected.
Steps to reproduce:
:set guiligatures==!><
Input text: != <= >=
Result: Characters are rendered individually rather than as a single ligature glyph.
The :version output shows -X11. While this is a GTK4 build, it is unclear if certain X11-specific integrations (like clipboard or session management) are intentionally disabled or if this is a configuration error in the build as you said before.
Thank you, this looks promising!
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
@mattn pushed 1 commit.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@mattn pushed 1 commit.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@mattn pushed 1 commit.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@mattn pushed 1 commit.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@mattn pushed 1 commit.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@mattn pushed 1 commit.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@mattn pushed 1 commit.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
Improved the toolbar appearance by using flat style buttons, which removes the raised/bordered look.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
@gonzaru Thank you for the detailed report! The three issues you reported have been fixed:
set guioptions=k — Fixed infinite recursion in gui_mch_newfont().Regarding -X11 in :version: this is intentional. This GTK4 port removes direct X11 dependencies. gvim no longer depends on X11 directly. It still works on X11 servers, but only through GTK4's GDK backend abstraction, not via direct X11 API calls.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
@gonzaru Thank you for the detailed report! The three issues you reported have been fixed:
g_set_prgname("gvim") so WM_CLASS is set correctly on X11.set guioptions=k — Fixed infinite recursion in gui_mch_newfont().Regarding -X11 in :version: this is intentional. This GTK4 port removes direct X11 dependencies. gvim no longer depends on X11 directly. It still works on X11 servers, but only through GTK4's GDK backend abstraction, not via direct X11 API calls.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
@mattn pushed 1 commit.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@mattn pushed 1 commit.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@gonzaru Thank you for the detailed report! The three issues you reported have been fixed:
1. **WM_CLASS empty** — Added `g_set_prgname("gvim")` so WM_CLASS is set correctly on X11. 2. **Crash on `set guioptions=k`** — Fixed infinite recursion in `gui_mch_newfont()`. 3. **Ligatures not rendering** — Ported the ligature rendering logic from GTK3 to GTK4.
Regarding
-X11in:version: this is intentional. This GTK4 port removes direct X11 dependencies. gvim no longer depends on X11 directly. It still works on X11 servers, but only through GTK4's GDK backend abstraction, not via direct X11 API calls.
I can confirm that 2. and 3 ara resolved. The crash is fixed and ligatures works!
About 1. the WM_CLASS reports:
WM_CLASS(STRING) = "gvim", "gvim"
Needs to be:
WM_CLASS(STRING) = "gvim", "Gvim"
This is how gtk2 and gkt3 also report its, as the class name the standard is to capitalize it.
The spec states that WM_CLASS must contain two consecutive null-terminated strings:
Instance Name: Identifies the specific instance (used for specific resource lookups).
Class Name: Identifies the general class of the application (used for grouping and general rules).
(4.1.2.5. WM_CLASS Property)
https://tronche.com/gui/x/icccm/sec-4.html
I will try to check more things this weekend and report it if necessary.
Regards
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
@mattn pushed 1 commit.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@gonzaru Thanks for the clarification on WM_CLASS.
WM_CLASS is an X11-specific property that GTK4 no longer sets directly. The correct way to handle this in GTK4 is through the StartupWMClass field in the desktop entry file. Added StartupWMClass=Gvim to runtime/gvim.desktop.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
@mattn Yes I understand to do not focus on x11 specific for now. As you said, the .desktop way can helps to this then, as it will add the correct class name on the fly.
Just in case, another small bug:
(crash on console dialogs)
It will show a console dialog, but the gvim freeze an does not respond anymore.
With the gui dialog: (with :set guioptions-=c)
Works, nut the text of the dialog are not labeled correctly and can confusing.
p1.png (view on web)—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
@mattn pushed 2 commits.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@gonzaru Thank you for the detailed reports! The following two issues have been fixed and pushed:
Console dialog freeze (guioptions+=c + confirm + :q) — The GTK4-specific exiting check in gui_mch_wait_for_chars() caused it to bail out immediately without waiting for key input. Removed to match GTK3 behavior.
GUI dialog button labels corrupted ("on" / "no" instead of "Yes" / "No") — The button label strings were used after the backing buffer was freed (use-after-free). Fixed the lifetime management.
Regarding the ligature issue at cursor position (#12901): this is a pre-existing bug that affects GTK2/GTK3 as well, not specific to GTK4. The cursor is drawn with gui_screenchar() which renders only a single character, breaking the ligature context that Pango needs. This will be addressed separately.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
@mattn Confirmed both (gui and non-gui dialogs) fixed. thxs!
I agree to focus more in gtk4 now in this PR than fix old gtk2/gtk3 know bugs.
A few more small ones I've just found:
***** Font completion (:set guifont=)
--
This is more cosmetic than a bug.
***** Menu greying (disabled items)
The gtk4 version treats all menu items as active, so even if there is no copy/cut/paste, it does not show the menu as "empty/grey".
(gtk3)
1000028920.jpg (view on web)
(gtk4)
1000028921.jpg (view on web)
--
***** :winpos always retuns 0
winpos can be useful for sessions with :set sessionoptions+=winpos and in the previous gtk's returns the correct window position.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
@mattn pushed 1 commit.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@mattn pushed 1 commit.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@mattn pushed 1 commit.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@gonzaru The remaining three items from your latest report have been fixed and pushed:
Font completion — :set guifont=\<TAB> now lists monospace font families from Pango, matching GTK3 behavior.
Menu greying — Disabled menu items (Copy/Paste etc.) are now greyed out using g_simple_action_set_enabled(). Also fixed the popover menu not closing after selecting an item.
:winpos — Unfortunately, GTK4 does not provide a window position API (removed by design for Wayland compatibility). gui_mch_get_winpos() now returns FAIL instead of reporting a misleading 0,0.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
@mattn pushed 1 commit.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@mattn pushed 1 commit.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
I added a native print dialog for :hardcopy on GTK4 GUI, similar to how
Windows GUI shows a print dialog. When the GUI is not running, the existing
PostScript path is used as before. If this is not desired, I can drop the
implementation — for now it can be disabled via #ifdef FEAT_GUI_GTK_PRINT.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
@mattn pushed 1 commit.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
WM_CLASS is an X11-specific property that GTK4 no longer sets directly. The correct way to handle this in GTK4 is through the
StartupWMClassfield in the desktop entry file. AddedStartupWMClass=Gvimtoruntime/gvim.desktop.
That's not correct. The intended use of StartupWMClass is for integration of a launcher that may have a different WM-CLASS than the application (think of a splash-screen style window). While it is frequently abused for cases where application developers cannot or will not make the WM-Class / Wayland App-id match the name of the .desktop file in this particular case it isn't actually going to do anything since vim doesn't use the capitalized Gvim and so that match would never happen anyway.
WM_CLASS(STRING) = "gvim", "gvim"
Needs to be:
WM_CLASS(STRING) = "gvim", "Gvim"
This is irrelevant in practice. All that ultimately matters is whether or not the DE/WM can associate a given window to the correct .desktop file, and I'm not aware of a single DE/WM that will fail to match a window against gvim.desktop just because the WM_CLASS is "gvim", "gvim" and not "gvim", "Gvim".
g_set_prgname("gvim")
According to this it sounds like using the GtkApplication constructor with the app_id as an argument should be preferred over g_set_prgname().
Honestly this would be a good time to unify app-id with the flatpak and just use org.vim.Vim for both WM_CLASS and app-id and also rename the .desktop file and icons to org.vim.Gvim.desktop. Users are already going to be in for a fairly noticeable change with the update to GTK4 so having to re-pin their launcher is probably not more disruptive.
Defaults to
GSK_RENDERER=cairobecause GL/Vulkan renderers may not be available in all environments. Can be overridden via environment variable.
I don't think you should do this globally. The default renderer should be preferred as it is hardware-accelerated, and if there are problematic platforms (like WSL2) then it would be better to check for those platforms at startup and only use cairo if they are detected.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
My window manager doesn’t handle this properly (yes you can duplicate rules, but usually lots of the programas are capitalized), so I had to catch it in a different way. Since GTK, GTK2, and GTK3 use “Gvim” instead of “gvim” as the class name, it creates inconsistency.
Yes, you can technically set it however you want, but why not follow the same conventions as before?
https://git.suckless.org/dwm/file/config.def.h.html#l29
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
@mattn pushed 1 commit.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
GTK4 does not provide a direct API to set WM_CLASS separately (unlike GTK2/GTK3 which had gtk_window_set_wmclass()). We use g_set_prgname("gvim") which sets both instance and class to "gvim". The StartupWMClass=Gvim in the desktop file handles the association for desktop environments. Using GtkApplication with a proper app_id would be ideal, but Vim's architecture doesn't currently use GtkApplication.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
The
StartupWMClass=Gvimin the desktop file handles the association for desktop environments
It does not, you are completely mistaken on that. The name of the .desktop file handles the association for desktop environments. $NAME.desktop is used to match X11 windows that have a WM_CLASS of $NAME or Wayland windows that have an app-id of $NAME. This PR sets the GTK4 X11 WM_CLASS and wayland app-id both to gvim, which matches the existing .desktop file, and so no further action is needed to ensure that windows are associated correctly.
Consider that if that were not true then window associations would be broken with the existing GTK3 UI and they are not.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
Is it affect to xterm-clipboard on CUI if X11 deps is removed by support of GTK4?
Mutter (Wayland Compositor on GNOME) doesn't support both of wlr-data-control-unstable-v1 and ext-data-control-v1, also developers say they never support it due to security concern (I am not familiar what is it).
Way to use system clipboard without steal of window focus will gone on GNOME if X11 deps is removed?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
You raise a valid concern. With --enable-gui=gtk4, the hybrid binary (same binary runs as both gvim and terminal vim) loses FEAT_XCLIPBOARD in terminal mode because the GTK4 build disables X11 dependencies entirely.
On GNOME/Wayland where Mutter doesn't support wlr-data-control-unstable-v1 or ext-data-control-v1, this means CUI clipboard access is limited to clipboard providers (e.g., OSC 52 via clipboardmethod=provider).
Keeping X11 linking in GTK4 builds could be a short-term workaround, but GTK5 will remove the X11 backend entirely, so it would only be temporary.
The long-term solution for terminal clipboard on Wayland is clipboardmethod=provider (e.g., OSC 52), which works independently of both X11 and Wayland compositor protocols. This is ultimately a GNOME ecosystem limitation (their decision not to implement wlr-data-control) rather than a Vim-specific issue, but it's worth documenting clearly.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
To add more context: the GTK4 build actually does enable FEAT_WAYLAND_CLIPBOARD (the WANT_WAYLAND definition in feature.h has no !defined(USE_GTK4) guard, unlike WANT_X11). Vim's Wayland clipboard implementation uses the wlr-data-control / ext-data-control protocols, so it works in terminal mode on compositors that support them.
| Compositor | CUI clipboard in GTK4 build |
|---|---|
| Sway, Hyprland (wlroots-based) | Works (wlr-data-control / ext-data-control) |
| KDE Plasma Wayland | Works (ext-data-control-v1) |
| GNOME/Mutter | Does not work (neither protocol supported) |
So on GNOME/Wayland with a GTK4 build, CUI Vim cannot use Wayland clipboard directly. However, this is a limitation on GNOME's side — Mutter has refused to implement ext-data-control-v1 even after it was standardized in wayland-protocols v1.39.
For workarounds in terminal Vim on GNOME/Wayland, you can use clipboardmethod=provider (e.g., OSC 52), or plugins like vim-fakeclip to integrate with xclip/xsel (which access clipboard via XWayland, and Mutter syncs it with Wayland clipboard).
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
@mattn pushed 1 commit.
—
View it on GitHub or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
@mattn pushed 48 commits.
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.![]()