Yanking from vim to Qt applications on Gnome

I’ve just noticed a weird issue here. I wonder if anyone can shed some light on it. I’m quite sure it’s related to the various clipboards that X11 and Wayland have, but it’s inconsistent and so confuses me. Here’s what I’m seeing:

  • run gvim
  • write some text
  • yank (copy) the text to the system clipboard using "+y (or select using the mouse and copy using Edit > Copy in Gvim).
  • try to paste the text (ctrl v) in gedit - it works
  • try to paste the text in Qutebrowser or Falkon (both Qt applications) - it does not work.

Vim uses the X11 clipboard from what I can find. So the yanked text goes to this clipboard, which is fine. But, why is it that gedit can access it but Qutebrowser/Falkon cannot?

Further, if I use something like wl-copy to add something to the Wayland clipboard, it is available everywhere—gedit, gvim, Qutebrowser. So, the wayland clipboard also updates the X11 one, but the X11 does not update the wayland one—is that what is happening here?

Package versions and system information:

=== fpaste 0.3.9.2 System Information (fpaste --sysinfo) ===
* OS Release (lsb_release -ds):
     "Fedora release 31 (Thirty One)"

* Kernel (uname -r ; cat /proc/cmdline):
     5.3.1-300.fc31.x86_64
     BOOT_IMAGE=(hd0,msdos3)/vmlinuz-5.3.1-300.fc31.x86_64 root=UUID=e6108b36-8dd0-4309-856e-697b664a7022 ro rhgb quiet plymouth.splash_delay=0 i915.fastboot=1

* Desktop(s) Running (ps -eo comm= | grep -E '(gnome-session|startkde|startactive|xfce.?-session|fluxbox|blackbox|hackedbox|ratpoison|enlightenment|icewm-session|od-session|wmaker|wmx|openbox-lxde|openbox-gnome-session|openbox-kde-session|mwm|e16|fvwm|xmonad|sugar-session|mate-session|lxqt-session|cinnamon)' ):
     gnome-session-b
     gnome-session-c
     gnome-session-b


libwayland-cursor-1.17.0-2.fc31.i686
wayland-devel-1.17.0-2.fc31.x86_64
libwayland-cursor-1.17.0-2.fc31.x86_64
libwayland-client-1.17.0-2.fc31.x86_64
libwayland-egl-1.17.0-2.fc31.x86_64
qt5-qtwayland-5.12.4-7.fc31.x86_64
ibus-wayland-1.5.21-2.fc31.x86_64
vim-common-8.1.2102-1.fc31.x86_64
vim-minimal-8.1.2102-1.fc31.x86_64
gnome-session-wayland-session-3.34.0-3.fc31.x86_64
wl-clipboard-1.0.0-0.2.20181215git7e5103c.fc31.x86_64
qutebrowser-1.8.1-1.fc31.noarch
xorg-x11-server-Xwayland-1.20.5-7.fc31.x86_64
libwayland-server-1.17.0-2.fc31.i686
libwayland-egl-1.17.0-2.fc31.i686
vim-filesystem-8.1.2102-1.fc31.noarch
wayland-protocols-devel-1.18-1.fc31.noarch
gnome-shell-3.34.0-3.fc31.x86_64
vimiv-0.9.1-11.fc31.x86_64
notmuch-vim-0.29.1-2.fc31.x86_64
vim-enhanced-8.1.2102-1.fc31.x86_64
libwayland-client-1.17.0-2.fc31.i686
libwayland-server-1.17.0-2.fc31.x86_64
vim-X11-8.1.2102-1.fc31.x86_64

Edit: Found an issue that may be related:

1 Like

Have you tried with xclip or xsel to use the X11 clipboard?

The “or” part here actually makes this way weirder. GNOME Terminal (and afaik all GTK terminals) use the Wayland APIs for clipboard management. So, this basically means that this isn’t working regardless of whether it’s copied from Wayland or Xorg…

Out of curiosity:

  • Can you reproduce this issue with any other apps?
  • Related to what @qulogic said, what do you see if you try pasting via both wl-paste and xclip/xsel? Are they identical results, or do xclip/xsel not work?
  • If you copy from a Qt application, can it paste elsewhere?
1 Like

Yes—this also turns out quite weird:

# In gnome terminal:

$ echo "YAY" | xsel -i 
# ctrl v in terminal doesn't paste "YAY". Pastes previously copied text.

$ echo "YAY" | xsel -i -p
# ctrl v in terminal doesn't paste "YAY". Pastes previously copied text

$ echo "YAY" | xsel -i -b
# ctrl v in terminal doesn't paste anything. Right click in terminal -> paste is greyed out.

Sorry–I wasn’t clear. This is in Gvim where using the menu to copy or "+y are identical.

I’ve checked Gedit: Copying there makes the text available everywhere: Qutebrowser and Vim.
I don’t know any other apps that are as specific as Vim about these things, though.

No. It is available in Gedit/Terminal, but in Vim, I get Nothing in register +.

So it looks like Vim uses the X11 clipboard, and while the other “native” apps sync the X11 and Wayland registers, this does not happen in Vim?

2 Likes

Can it be a bug in gVim? It can be using some X11-specific commands/calls instead of using more generic ones (as more modern applications do) which are correctly synced between X11 and Wayland registers?

Yes, I think that is the case. Instead of using the cliboard mechanism provided by Gtk (or whatever), I think Vim specifically works with the X11 bits. So, it does not take advantage of the X11-Wayland clipboard sync that Gtk does for the applications?

I’ve just did a quick test (I use vim in cli only, don’t use gVim myself), in my case anything I’ve copied from gVim using “Edit - Copy” method did happily pasted in gnome-terminal.

And in qutebrowser (in the search field on a webpage) too… In the qutebrowser’s command prompt also.

1 Like

Ah, you’re right! I created a new user and it works fine there. So it’s something to do with my user here then :slightly_frowning_face:

Text yanked from vim is available in gnome-terminal to paste. So would it be fair to say that this is caused by something on the Qt config side of things?

I though about this too after writing about gnome terminal.

But it’s logical then, that this trouble shouldn’t be just between gVim and QT apps, it should appear between some QT apps and some other X11? GTK2? apps as well.

One easy to check (for similar behavior) app should be xterm, if you think of others I can try them on my side too.

No, turns out xterm is BAD variant because it don’t use clipboard (I haven’t known this) ))) It can be asked to do so – but for our purpose it’ll be easier to test something else.

I couldn’t find anything. I’ve ensured that it isn’t my vim settings by running gvim as so: gvim -u NONE (this runs without any vimrc settings). There’s nothing in my bashrc either. I couldn’t find any related settings in dconf-editor and i don’t know where to begin looking for Qt related settings…

Did a bit of searching. Possibly hitting this?

https://bugreports.qt.io/browse/QTBUG-74330

1 Like

I really don’t know. I can’t find anything anywhere. For the time being, I give up :sob:

All ideas/suggestions are welcome.

Waaaiiitt! I take this back. The new user was running Gnome-shell under Xorg. When I logged in using the default (Wayland), the issue also persists in the new user. So it is not limited to my user only.

Here’s something new. While gedit is open, copying from it sets the X11 and wayland clipboards. When gedit is closed, the X11 clipboards are cleared. Video here:

gedit-X11-clipboard.webm

  1. I’ve checked, I’m in a wayland session, and it worked for me.

  2. Watched the video, can you test the same, but instead of closing gedit just remove the selection – so that there isn’t any selected text in gedit?

If it’s still clears the clipboard (or rather selection buffer) – then I believe that’s by design.


I’ve read X11 has two buffers: selection buffer that contains just the currently selected text. This is used traditionally with middle-click to paste.

And the second one is more traditional clipboard (so to say) used with Ctrl-C / Ctrl-V and/or Ctrl-Insert / Shift-Insert. As I’ve said several posts before, it turns out xterm doesn’t support clipboard’s copy/paste, only more traditional (legacy?) text selection buffer.

Behavior you demonstrated in your video correspond to this text selection buffer containing something or being empty.

Are you on F31 with Gnome-3.34?

No, I’m on 30 with 3.32 ) Meant to ask you the same but thought you’d mention non-default state so to say ))

Ow, and I’ve missed the tag ))

1 Like

And the sysinfo output :stuck_out_tongue:

But at least this confirms that it worked as expected with F30 and Gnome 3.32. So it’s a regression in 3.34 and F31. (and also that I’m not crazy :laughing:)

1 Like

Your’re right on both points here!.. I sort of seen sysinfo’s there, but it didn’t clicked in my mind somehow) Sorry for the confusion )

1 Like

No worries—I was really beginning to think of a fresh install here, so knowing that it’s probably a regression helps. I’l writing to the test mailing list now. Let’s hope this is either a known issue or one that needs fixing.

In the meantime, if anyone is running F31, please feel free to test the issue and make suggestions.

Posted to the workstation ML:

https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject.org/thread/QLVJJRUITIVJR7ASUFTAXPXIOXPBSLPM/