[vim/vim] Initial Wayland support (PR #9639)
依云
This adds native Wayland support (#4727). The main advantage is on HiDPI displays where xwayland windows may be blurry. I've been using this for quite some time and it seems to work fine, except the following unfinished features:
+clientserverdepends on X11 and thus no longer works. It may be replaced by using D-Bus to communicate instead- clipboard support in terminal may be limited as it's using X11 clipboards. There is nothing to lose however; vim behaves this way without this patch.
- on wlroots-based Wayland compositors xwayland clipboards don't sync with wayland native ones when no xwayland window is focused (I didn't test other compositors)
- on wlroots-based Wayland compositors there is a
zwlr_data_control_manager_v1protocol can be used to access clipboards - users can use wl-clipboard to work around this issue in some cases
- it can't be built without X11 support
Because +clientserver is unavailable when Wayland support is enabled, I put this feature behind an environment variable GVIM_ENABLE_WAYLAND to opt in (like what Firefox does with its MOZ_ENABLE_WAYLAND). This is temporary and once +clientserver support is added it can be removed.
You can view, comment on, or merge this pull request online at:
https://github.com/vim/vim/pull/9639
Commit Summary
- 4fbb72b wayland initial run!
- 289627e selections finally work
- 83d913b dedup gui_gtk_set_selection_targets code
- 79d109d fix some "drawable is not a native X11 window" warnings
- 81eba24 fix clipboard not correctly handled
- 16d8e3f reduce some display server traffic
- 3a37cac fix title not updated in wayland
- 4d85da9 wayland clipboard: request text/plain type too
- aac54ca clipboard: prefer text/plain;charset=utf-8
- cc01959 make balloon eval window children of main window to position correctly
- 150938f use an environment variable to enable unfinished Wayland support
- 5ce69f0 update tests
File Changes
(12 files)
- M src/clipboard.c (4)
- M src/gui_beval.c (1)
- M src/gui_gtk_x11.c (165)
- M src/os_unix.c (5)
- M src/proto/gui_gtk_x11.pro (2)
- M src/testdir/check.vim (8)
- M src/testdir/test_clientserver.vim (2)
- M src/testdir/test_gui.vim (2)
- M src/testdir/test_python3.vim (4)
- M src/testdir/test_quotestar.vim (4)
- M src/testdir/test_startup.vim (12)
- M src/testdir/test_vim9_builtin.vim (2)
Patch Links:
—
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
依云
Marc Mezzarobba
I tried this patch and it seems to work well for me, thanks!
One minor issue: when moving a gvim gui window from a low-dpi (1:1) to a hi-dpi (1:2) display, the text initially looks blurry, until I resize the window. (Running :redraw or scrolling is not enough.) GTK menus are not affected.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
Looking at the patch, it appears to be a compile time change to build Vim for Wayland. The #ifdefs are missing still.
I was wondering if it is possible to build Vim in a way that it runs both on X11 and Wayland. Thus make the difference at runtime. That there are no changes to configure or Makefile suggests that this would work. Vim would detect very early it's on Wayland, set a global variable, and then check the value of that variable where the changes in this PR are done. Would that work?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
依云
It does work for both x11 and Wayland (GTK handles that), only that some features are missing on Wayland (+clientserver, +clipboard in a terminal).
when moving a gvim gui window from a low-dpi (1:1) to a hi-dpi (1:2) display, the text initially looks blurry, until I resize the window
Yes, I've noticed that. I haven't figured out how to fix this though.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Marc Mezzarobba
Something else that I didn't notice at first: two-finger scrolling using the touchpad stops working when GVIM_ENABLE_WAYLAND is set. Curiously, scrolling using the mouse wheel works regardless of GVIM_ENABLE_WAYLAND.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
依云
I fixed the blurry issue, but a little dirty (fake a resize event): lilydjwg@f48d7db.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
依云
Wayland has native touchpad support, so it doesn't emulate a mouse wheel anymore.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
依云
@mezzarobba lilydjwg@8bc6b50 handles touchpad scrolls.
I'll rebase these commits to this pull requests later.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Marc Mezzarobba
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
I see a few things that indicate this is not ready to include yet. Deleting lines from clip_copy_selection() should most likely be replaced by skipping those lines when in Wayland mode.
That also means we need a function that returns TRUE when using Wayland instead of X11.
The change in gui_mch_early_init_check() suggests that checking for $WAYLAND_DISPLAY could be used.
But what if $DISPLAY is also set?
The $GVIM_ENABLE_WAYLAND variable needs documentation.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
依云
@lilydjwg pushed 15 commits.
- 9b1fddf wayland initial run!
- 80c72f9 selections finally work
- 22b6d60 dedup gui_gtk_set_selection_targets code
- 019f690 fix some "drawable is not a native X11 window" warnings
- 400d68d fix clipboard not correctly handled
- 0def971 reduce some display server traffic
- 1f6c1a9 fix title not updated in wayland
- 4c24f17 wayland clipboard: request text/plain type too
- c71dd30 clipboard: prefer text/plain;charset=utf-8
- 0d5c13b make balloon eval window children of main window to position correctly
- efeecdb use an environment variable to enable unfinished Wayland support
- 2bb713e update tests
- 7b63037 remove #if because we use gui_mch_get_display in more places
- 0520b80 gtk2 doesn't have GDK_IS_X11_DISPLAY
- f4102f9 fix misplaced closing parenthsis
—
View it on GitHub or unsubscribe.
You are receiving this because you are subscribed to this thread.
pebble2050
it will be even better if support system dark mode.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
依云
it will be even better if support system dark mode.
This uses dbus, not wayland. I hope someday someone (or I) can introduce dbus and implement +clientserver via dbus, and after that, adding an event indicating dark / light mode should be easy.
BTW it's been a long time and I'll revisit this patch in the future.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Capmus Banon
Any milestone for this must have feature? I just migrate from i3wm to sway and realize vim is the pain in the butt. How could the vim community leaves behind the curve.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
For a very long time X11 has been part of the foundation of Unix programs.
You can't expect programs to switch over to a different foundation just like that.
Why don't those that want to use Wayland spend time to help port programs to it?
I would expect it to be much more efficient if a group of developers understand how to port
a program from X11 to Wayland, then developers of every program to figure out how to do that.
Anyway, this PR is work in progress, please help out if you know how to do part of it.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
@moralrebuild so have you tried out the PR and can provide feedback?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
jclsn
@chrisbra I just tried it. The clipboard doesn't work for me unfortunately.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
依云
@jclsn are you using gvim or terminal one? What is 'clipboard' option set to?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
jclsn
@lilydjwg I only install gvim because I am too lazy to compile vim with the clipboard. I tried both now, gvim and the terminal version. The clipboard works with the copy button, but not when I use "*y.
My clipboard is currently set to clipboard=autoselect,exclude:cons\|linux, but I also use vim as a scrollback pager for my Kitty terminal, where I load a minimal configuration that sets clipboard=unnamedplus. Both don't work unfortunately.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
依云
Terminal vim won't work (if it ever does, it does so via xwayland).
Both clipboard=unnamedplus and `"*y" worked for me. What's your operating system, Wayland compositor and GTK 3 version?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
jclsn
Terminal vim won't work (if it ever does, it does so via xwayland).
Why won't in work it wayland? Isn't it just a matter of implementation?
I am using Arch Linux and KDE, so I guess my Wayland compositor is KWin. GTK3 version is 3.24.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
依云
Why won't in work it wayland? Isn't it just a matter of implementation?
There are two protocols to access the clipboard in Wayland. One is in the core protocol, which requires a focused window to function, but terminal Vim obviously doesn't have one. wl-clipboard creates a tiny window to work around this but it's disturbing. The other is a wlroots protocol that only works for a wlroots-based compositor.
And, neither is implemented in Vim yet.
I'll take a look in KDE later.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
依云
I tried in my Arch KDE virtual machine, but it didn't reproduce. Are you using some clipboard management tool (either you explicitly run or comes with your desktop by default)? Also I'd like to see a screencast demo. You can use showmethekey for showing typed keys.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
jclsn
showmethekey does only support the US keyboard layout it seems and screenkey does not work properly. So I can't really record that I fear.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
jclsn
Ah well, I did make a video back then. Since I use a German keyboard though, the strokes you see won't be of much help.
https://github.com/vim/vim/assets/19779511/6b85b42f-791a-485d-a52a-eb5ff818ea75
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
依云
Since I use a German keyboard though, the strokes you see won't be of much help.
It's not hard to manually map those key names onto a German layout.
I see you tried to use Ctrl-Shift-v to paste. This worked in terminal vim because the terminal interpreted it as paste and sent a sequence to Vim saying the user had pasted the content. (copy-to-clipboard didn't work and it's expected.)
However it didn't work in GVim because GVim didn't interpret it as paste. Instead, GVim thought it was Ctrl-v and inserted the next key literally, which was Esc (displayed as ^[). You need to use "+p to paste what you have "+y-ed.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
jclsn
Since I use a German keyboard though, the strokes you see won't be of much help.
It's not hard to manually map those key names onto a German layout.I see you tried to use
Ctrl-Shift-vto paste. This worked in terminal vim because the terminal interpreted it as paste and sent a sequence to Vim saying the user had pasted the content. (copy-to-clipboard didn't work and it's expected.)However it didn't work in GVim because GVim didn't interpret it as paste. Instead, GVim thought it was
Ctrl-vand inserted the next key literally, which was Esc (displayed as^[). You need to use"+pto paste what you have"+y-ed.
Ah yes this works in GVim. Pity that it doesn't work in the terminal though. I have found this plugin now which adds this functionality.
https://github.com/jasonccox/vim-wayland-clipboard
Would be nice if this plugin weren't needed for this.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Fredrik Roubert
For the past few weeks I've been using a gvim binary built from this PR in order to get sharp Wayland font rendering with GNOME 44 and fractional scaling and it has worked very well, I haven't encountered any bugs yet and the font rendering is just as it should be, high resolution and the correct size.
Is there now something I could do to help this PR towards getting merged?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
依云
Glad to hear that. I didn't expect fractional scaling to work without further changes actually.
I have some other fixes that hasn't been pushed here yet. I'm going to do a rebase and get all related commits onto this soon.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
VZ
This is not really a problem with this PR but, just to warn other users, it's very easy to crash GVim when using GTK/Wayland due to this bug. I've had to use this horrible hack to allow me to run %v/whatever/d on a file without crashing and, ugly as it is, I wonder if it could be worth it to integrate this into Vim itself until GTK fixes this.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
依云
That is a horrible crash, especially GTK calls _exit, disregarding all atexit handlers (the original GTK comment says it disable our atexit(), making me trust GTK even less). But it shouldn't cause too much data loss anyway, as Vim is always prepared to a sudden crash.
I didn't reproduce the crash though. Maybe it's compositor-related. Also I don't know how to overwrite a library function in the application code.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Marc Mezzarobba
> I didn't reproduce the crash though. Maybe it's compositor-related.
I suppose it makes sense that the procedure to trigger the crash
described in the linked issue is specific to Gnome.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
cwegener
Just tried on GNOME 44 and I can't reproduce the crash either (I tried with the %g/./d ex command from the gtk issue tracker)
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Marc Mezzarobba
> that it happens on `%v/whatever/d` indicates you have likely `:set
> clipboard=unnamed` or similar and after the `:g` command finishes,
> Vim tries to sync with the system/wayland(?) clipboard
I tried with a couple of settings of `clipboard` and still can't
reproduce the issue under kwin.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
VZ
Sorry, it seems like I underestimated the size of file needed to reproduce this and didn't realize it was related to using :set clipboard=unnamed (thanks @chrisbra for your psychic debugging!).
So first of all 100 lines is not enough and neither is 300 -- but 400 is. And you don't even need to run the command interactively, but you do need to set clipboard to unnamed:
$ seq 1 400 > t $ gvim -u NONE -U NONE -c ':set clipboard=unnamed|%v/2/d' t Gdk-Message: 16:19:35.981: Error flushing display: Resource temporarily unavailable
(if you add -f you can also see that it exits with 1 and not 0). Please let me know if you can reproduce it now?
This is under GNOME 43.6 (Debian Bookworm), but I'd be surprised if it were GNOME-version dependent, this really looks like a GTK problem.
Also:
That is a horrible crash, especially GTK calls
_exit, disregarding allatexithandlers
Exactly. I really can't fathom the thought process of a library author deciding to use _exit().
But it shouldn't cause too much data loss anyway, as Vim is always prepared to a sudden crash.
True, luckily I didn't lose any of my edits, but I still lost the commands history which was annoying (I don't know if it's normal that it didn't get stored in viminfo, but this is a different issue, I think).
Also I don't know how to overwrite a library function in the application code.
Well, the ugly hack with defining your own wl_display_flush(), delegating to the function loaded using RTLD_NEXT and retrying if it failed with EAGAIN as I did in the linked gist is one (and AFAICS the only one) way to do it.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Marc Mezzarobba
> ```console
> $ seq 1 400 > t
> $ gvim -u NONE -U NONE -c ':set clipboard=unnamed|%v/2/d' t
> Gdk-Message: 16:19:35.981: Error flushing display: Resource
With this I *can* reproduce the issue, though not systematically.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
cwegener
I can confirm that the new instructions allow me to reproduce the issue as well now.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
依云
@lilydjwg pushed 17 commits.
- f5996c6 wayland initial run!
- 8ac958c selections finally work
- 89ae082 dedup gui_gtk_set_selection_targets code
- caed3f0 fix some "drawable is not a native X11 window" warnings
- f35994c fix clipboard not correctly handled
- 989796c reduce some display server traffic
- 7a9dbd6 fix title not updated in wayland
- 7264c1b wayland clipboard: request text/plain type too
- 48791ef clipboard: prefer text/plain;charset=utf-8
- 9e06665 make balloon eval window children of main window to position correctly
- 8037365 use an environment variable to enable unfinished Wayland support
- 877c45f update tests
- db52d2b remove #if because we use gui_mch_get_display in more places
- e37497c gtk2 doesn't have GDK_IS_X11_DISPLAY
- e5fefa4 force redraw on scale factor change
- 47fa365 handle smooth scroll events (touchpad events on Wayland)
- b05737a fix code style
—
View it on GitHub or unsubscribe.
You are receiving this because you are subscribed to this thread.
依云
One test Test_geometry is failing but I don't know why. It produces the correct result on my machine.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
依云
@lilydjwg pushed 0 commits.
You are receiving this because you are subscribed to this thread.
Fredrik Roubert
I've now noticed one thing that doesn't work when running gVim in Wayland using this PR: v:windowid is always zero.
I see that this is a known issue, as the PR updates test_gui.vim to expect this, and I don't know enough about how Wayland actually works to be able to tell whether it'd actually be possible to set it to anything useful, but I felt that I wanted to highlight this just in case someone else wonders about it in the future.
That said, I've used gVim in Wayland using this PR daily for several months now and it works just fine for me, so I'd find it very nice if this PR could get merged (and please just tell me if there's anything I can do to help).
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Coelacanthus
I've now noticed one thing that doesn't work when running gVim in Wayland using this PR:
v:windowidis always zero.I see that this is a known issue, as the PR updates
test_gui.vimto expect this, and I don't know enough about how Wayland actually works to be able to tell whether it'd actually be possible to set it to anything useful, but I felt that I wanted to highlight this just in case someone else wonders about it in the future.
Wayland has no window ID. The only similar thing is the app ID, but the app ID is a string, not a number.
https://wayland.app/protocols/xdg-shell#xdg_toplevel:request:set_app_id
That said, I've used gVim in Wayland using this PR daily for several months now and it works just fine for me, so I'd find it very nice if this PR could get merged (and please just tell me if there's anything I can do to help).
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
依云
The app id is for the app, not the window. There is a way to identify a window in wayland recently, but I don't expect to be able to get this in GTK3 (which is basically feature-frozen). (It's also a string btw.)
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
One test Test_geometry is failing but I don't know why. It produces the correct result on my machine.
That one is strange. I just checked it and it is failing consistently for me in the current state. Initially, I thought it's the toolbar, that's causing the test failure, but even if I disable the toolbar, it still fails with Expected '13' but got '11'. (it happens for me with both the GTK2 as well as the GTK3 builds).
However, I just played around with the -geometry argument (using GTK3), and noticed with larger values it starts to working again. By testing it out, I see the limit where it starts to fail is using a Columns setting of less than 36. So this works fine: -geometry 36x13+41+150 and this one fails: -geometry 35x13+41+150. (and the latter returns 11 as the number of lines. In addition, I start to see the following GTK Error: gtk_distribute_natural_allocation: assertion 'extra_space >= 0'.
Can you try this patch in addition please? It would just use a bigger gvim window. I suppose the error is somewhere deep in the GTK libraries, so have no other ideas how to fix it.
diff --git a/src/testdir/test_startup.vim b/src/testdir/test_startup.vim
index a237e98b1..9400fe91f 100644
--- a/src/testdir/test_startup.vim
+++ b/src/testdir/test_startup.vim
@@ -521,12 +521,12 @@ func Test_geometry()
" Hide menu because gtk insists to make the window wide enough to show it completely
" Some window managers have a bar at the top that pushes windows down,
" need to use at least 130, let's do 150
- if RunVim(['set guioptions-=m'], after, '-f -g -geometry 31x13+41+150')
+ if RunVim(['set guioptions-=m'], after, '-f -g -geometry 40x13+41+150')
let lines = readfile('Xtest_geometry')
" Depending on the GUI library and the windowing system the final size
" might be a bit different, allow for some tolerance. Tuned based on
" actual failures.
- call assert_inrange(31, 35, str2nr(lines[0]))
+ call assert_inrange(40, 45, str2nr(lines[0]))
call assert_equal('13', lines[1])
" on Wayland there is no way to set or retrieve window positions
if empty($WAYLAND_DISPLAY)
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
I left a few comments. However, it seems we have a few GTK related changes, that may not directly relate to Wayland support? Can we clean up such that we have one patch for the GTK improvements, and 1 patch for Wayland support? Also, I am missing some documentation. E.g. that v:windowid is no longer available, the restrictions to getwinposx(), getwinposy() , and getwinpos() and the GVIM_ENABLE_WAYLAND environment
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
依云
@lilydjwg pushed 2 commits.
You are receiving this because you are subscribed to this thread.
依云
v:windowid documentation already says it's available only in X11 or Windows.
For getwinpos*, I'm updating them to return -1 on Wayland, as the documentation says if unavailable -1 is returned.
For GVIM_ENABLE_WAYLAND, I'm considering dropping it, or turn it from opt-in to opt-out. The Wayland support has been here for some time and no new bugs are reported. The only missing piece is the +clientserver feature. What do you think?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
okay sounds like a plan. I am slightly worried the clipboard related changes will cause regressions on the X11 backend however.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
依云
I got the Test_geometry failure locally. It doesn't happen with Wayland, and it doesn't happen when I manually run the command and check &lines. In the test the window starts as expected but soon it shrinks as the window title is updated.
I've got &column mismatch with master code though.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
what happens if you disable the toolbar, similar to how you disable the menubar?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
for column mismatch, we already use the assert_inrange() I believe. So it must be an old problem
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
依云
The same. It shrinks before the menubar is disabled, and so same for the toolbar. Maybe we can use inrange for it too?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
Thanks. I have made a few style changes, fixed the test and removed the changes for the clipboard. Please see if this works fine.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Maxim Kim
Thank you!
Didn't test extensively yet, but works like a charm in WSL2:
$ GVIM_ENABLE_WAYLAND=1 gvim &
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Hugo
The app id is for the app, not the window. There is a way to identify a window in wayland recently, but I don't expect to be able to get this in GTK3 (which is basically feature-frozen). (It's also a string btw.)
FYI: The ext-foreign-toplevel-list-v1 protocol is a privileged one, reserved for things like a dock, window switcher, etc. Clients like Vim cannot rely on it, even if the toolkit makes it available.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
so WSL2 exposes Wayland? That is pretty cool, thanks for sharing.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Fredrik Roubert
After the first day with gVim built from v9.1.0064 running in Wayland on Linux everything seems to be working great, thanks!
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Maxim Kim
Tested a bit more in GNOME wayland and Sway:
- In GNOME everything works just fine (terminal/GUI)
- In Sway, the same vim, has a significant startup delay ~1second, i.e.
vim -Nu NONEstarts slow.
Not sure if this is related though, didn't bisect to figure it out.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
依云
@habamax that delay may be caused by xwayland starting up (terminal Vim may still try to connect to X for clipboard & +clientserver stuff). Try env -u DISPLAY vim and do you get any difference?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Maxim Kim
@lilydjwg tried it, same delay.
Unsetting GVIM_ENABLE_WAYLAND has no effect as well.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Maxim Kim
I have compiled version pre patch v.9.1.0063 and it has the same issue, so patch is not a problem.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
A.F.
thank you!!!
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.