Thanks for working on that. I think that makes sense. Do I understand correctly, that this should not break anything on GUI (GTK3) Vim?

Thanks for working on that. I think that makes sense. Do I understand correctly, that this should not break anything on GUI (GTK3) Vim?

No errors or crashes will occur. However it is not backward compatible. Users who currently use numeric cursor shape IDs or any of the following vim shape names will see different icons. The underlying issue is that gdk_cursor_new_from_name supports fewer cursor shapes than gdk_cursor_new/GdkCursorType does. The latter is based on X11 conventions that are being deprecated by GTK.

• hand1
• hand2
• pencil
• rightup-arrow
• up-arrow

Okay, so it looks like we will have those 'mouseshapes':

(System is w for Windows and x for X11, perhaps we should add a G for GTK).

Missing:

I am a bit surprised we don't have beam and busy. But when this is no longer supported by the underlying library :/

Currently the help states also this:

Any modes not specified or shapes not available use the normal mouse pointer.

So it seems more or less okay? Can we keep the current cursor shapes when we still use GTK2/3 UI?

We will have support for the vim names beam and busy. They translate to the CSS names text and progress. Here's a couple of screenshots showing how those look on my screen with vim -g --clean -U /dev/null. Please ignore the cursor size. It appears comically large here because the (a) it is configured to be extra large by preference and (b) the default font size is very small.

I like the idea of adding a g for GTK to that table. I'll incorporate that into my next update.

Regarding when to adopt this, I don't have a firm preference. I wanted to start on this because it is coming eventually and would take some discussion. If it is best to delay this until GTK4 that is fine with me. I think one argument for adopting this in GTK3 sooner rather than later relates to GTK2 support. I don't yet have a firm grasp on how hard it will be to maintain support for all of GTK2/3/4. Whatever the absolute effort required, on a relative basis it would be considerably easier to support any two versions of GTK at once. This seems to have been the approach so far. If we decide that we will support only GTK3/4 in vim10 then I think there's two ways to approach that:

• We could decide that vim with GTK is meant to lean into all of the GTK-isms, including only supporting the X11-isms that have direct Wayland couterparts. This would make Motif the primary means of accessing X11-isms.
• We could instead decide that vim's GTK3 integration will opt into all of the X11-isms to allow people to maximize their use of X11 until GTK5 support is added. This would mean the only way for gvim users to maximize their use of Wayland would be to use GTK4.

The first option would argue for merging this now. The second option would argue for folding this into the much larger effort to support GTK4.

We currently have a kludge that shunts vim users into X11 even with GTK3 unless they explicitly opt into Wayland. I think that was good when it was added but eventually this will have to be removed.

#if GTK_CHECK_VERSION(3,10,0)
    // Vim currently assumes that Gtk means X11, so it cannot use native Gtk
    // support for other backends such as Wayland.
    //
    // Use an environment variable to enable unfinished Wayland support.
    if (getenv("GVIM_ENABLE_WAYLAND") == NULL)
	gdk_set_allowed_backends("x11");
#endif