`Paste` from `Edit` menu won't paste from system clipboard

[zcobol]

• add some data to the system clipboard
• open Edit drop-down menu and select Paste
• expected clipboard content to be pasted into the buffer

Typing ctrl-v will paste from the system clipboard, however using the command from the drop-down menu won't.

[lhecker]

To my knowledge most terminals don't have the required OSC 52 sequence enabled by default. I feel like this makes the use of that sequence rather questionable. I wonder if it would make sense to add optional support for it once we support settings (#22).

[unxed]

Kovid Goyal's kitty terminal supports OSC 52, it is enabled by default, and this terminal presents in Debian and Fedora repos. far2l (Far Manager Linux port, presents at least in Debian) internal terminal also supports it. Windows Terminal also supports it.

Another trick is to connect to X11 (or Wayland) and manipulate clipboard throug it. We use this method in far2l if OSC52 is not available. All graphics server interaction is done from separate .so which is not loaded if no graphics server is availbe on host system. The problem of this method is that it requires X forwarding to work over ssh (also X forwarding is often disabled on the server side). Yet another way of implementing this is to allow user to specify command line tools (and their syntax) for clipboard access, like xclip.

See also:
microsoft/terminal#2946
elfmz/far2l#1422

[ket000]

When I launch using putty 0.83 running on Windows 11 remote ssh session to Oracle Linux 8.10 and try to copy paste using ctrl +c or Menu copy paste from windows clipboard, it does not work. Only workaround I found is to use Putty paste command opened from the putty settings. Copy still does not work. Only way to make it work is to use copy all to clipboard which is not pretty. Hopefully we can find a solution to make it work using putty and windows system clipboard. for e.g. it works fine when using nano. I have copy on select turned on for putty settings.

Please see the link : https://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/osc.html where developer mentioned why he will not enable the OSC support.

Please not when using Windows Terminal App and using windows ssh.exe it works fine using Ctrl + c and Ctrl + v. Menu copy paste also works.

[unxed]

This putty fork (yet another kitty, by cyd01) has OSC 52 enabled. It's me who implemented it :)

btw, if you want Edit-like console text editor with word wrap and clipboard support via OSC52 that already works, you can use turbo until OSC 52 support is ready in Edit. It will suit your needs. tilde editor is similar and also uses some magic for clipboard access (X11 interaction? I am not sure).

[lhecker]

FWIW what I meant was specifically the copy-from-clipboard portion of OSC 52. Windows Terminal only has copy-to-clipboard enabled by default. I believe many other terminals are the same, hence my statement.

I'm not actually opposed to fixing this, but I am somewhat hesitant about it. I'm a little worried that adding support for X11, etc., may go beyond the scope of the project for the near term. It may be easier to address this in the long term as the overall architecture becomes more robust.

OSC 5522 seems really nice though. It's just not very widely supported yet, is it? (I don't want to introduce sequences supported only be few terminals just yet, for similar reasons.)

[unxed]

Copying from the clipboard can work quite well in "bracketed paste" mode, which is supported in most terminals. But I have not come across support for OSC 5522 anywhere except Kovid Goyal's kitty.

As for clipboard manipulations via X11 interaction, this can be added last, via an optional module that is not critical for the editor to work, or not added at all. Personally, this is not critical for me, I have a terminal with OSC 52 and Bracketed paste.

[DHowett]

Edit already requests bracketed paste. :)

[kayahr]

I love msedit, but the missing integration of the system clipboard on Linux gets more and more a deal breaker for me. Pasting from system clipboard somehow works by Pressing Ctrl-Shift-V which is actually a Gnome Terminal Shortcut to paste the text into the terminal. But copying stuff from msedit into the system clipboard is pretty much PITA. I can select text by holding down the Shift key and then press Ctrl-Shift-C to tell the Gnome Terminal to copy the selected text, but this only works for text in one line. As soon as I select multiple lines then this also copies the line number and part of the scrollbar.

Another annoying scenario: Opening file A, select some text and copy it to the clipboard. Exit editor and open file B, pasting the clipboard. Nothing happens because msedit uses an internal clipboard which is gone when exiting the editor. Sure, I can open both files at once and switch between them... But with integration of the system clipboard this would simply work.

With the micro editor this works painlessly. I think it uses the xclip program for this. Not sure if this also works with Wayland, though... Maybe on wayland you need to use wl-clipboard.

Maybe it's time for msedit to have a configuration file? mcedit(the editor from Midnight Commander) by default also has no integration into the system clipboard but it can easily be configured to use xclip or wl-clipboard by setting up the necessary commands in the config file. So by default msedit can do what it does now but when commands for copy/paste are configured then it uses this instead.

[j4james]

@kayahr Note that this is mostly a VTE issue - the maintainers don't think applications should be allowed to copy to the clipboard so they don't support the OSC 52 sequence that is needed for this to work (see https://gitlab.gnome.org/GNOME/vte/-/issues/2495).

Most other Linux terminals should work fine (e.g. Alacritty, Contour, Foot, Konsole, Kitty, Ghostty, MLTerm, WezTerm), although you might need to enable clipboard support in the config first in some cases.

[pm64]

I'm more than a little perplexed as to why this issue has been flagged "low priority", since the ability to copy/paste using the system clipboard has been a basic expectation for over 40 years. So I'm assuming this decision was not made by a human.

May I propose an actionable solution? Instead of shifting the burden to terminal implementors to support OSC 52, simply check for xsel, xclip, and/or wl-clipboard -- and prefer those tools over OSC 52 for clipboard access. Give the user a path that doesn't involve a change as disruptive as moving to a new terminal.

To consider a feature like copy/paste "low priority" sends a message to the community that I don't think you're intending to send.

[unxed]

You can even use an additional .so that is loaded only if X11 is present, that uses direct X11 calls for clipboard access (as we do in far2l)

OSC52 advantage is that it does not require X11 forwarding to work on remote systems via ssh and also having xlib installed on them, so better to support both ways