Just letting you know I am still working on this, thus leaving this for input.
I have spend time polishing and minimizing the tiny version, but have everything else implemented for normal,huge, but I need to merge it into my new base and its getting late.
Plan:
[ --enable-osc52[=OPTS] (not supported with --enable-gui)
OSC 52 Clipboard [default=yes] [OPTS=no/yes/only]], , enable_osc52="no")
yes
only
x11,wayland in configure making a super minimal clipboard terminal setup.When enabled :version:
+osc52
+clipboard
Because the features are similar to regular clipboard but it does not have clipboard_provider etc. All other code is bypassed, it does not enable FEAT_CLIPBOARD it just shows the feature as it is otherwise fully compatible with the provided features.
(most relevant to tiny version, but also works on regular build)
VIMOSC52=1, enables "+, and "* registers loading content at startup from OSC52 p,c primary/clipboard
Functions as an entrypoint for your regular sysadmin/devops who have no readwrite access/forbidden to customize config and just want clipboard working remotely on servers he trusts.
clipboard.c on regular buildCurrent suggestion is that it defaults to wayland,x11,osc52 if built with --enable-osc52=yes.
If VIMOSC52=1 is used on regular build it reorders clipmethod to
clipmethod=osc52,wayland,x11
Meaning it prioritizes it first.
vimrc configuration is an explicit, non-default - ordered to your liking.
set clipmethod=osc52,wayland,x11
Configuration is explicit, non-default, always for this feature.
options.txt
*'clipmethod'* *'cpm'*
'clipmethod' 'cpm' string (default for Unix: "wayland,x11",
with OSC 52: "wayland,x11,osc52",
with OSC 52 only: "osc52",
for VMS: "x11",
otherwise: "")
global
{only when the |+xterm_clipboard|, |+wayland_clipboard|,
or |+eval| features are included}
|+osc52| or |+eval| features are included}
Specifies which method of accessing the system clipboard (or clipboard
provider) is used. Methods are tried in the order given; the first
working method is used. Supported methods are:
wayland Wayland selections
x11 X11 selections
osc52 OSC 52 terminal clipboard.
{only non-gui when compiled with |+osc52|}
See |clipboard-osc52|.
<name> Use a clipboard provider with the given name
Note: This option is ignored when either the GUI is running or if Vim
is run on a system without Wayland or X11 support, such as Windows or
macOS. The GUI or system way of accessing the clipboard is used
instead, meaning |v:clipmethod| will be set to "none". The
is run on a system without Wayland, X11, or OSC 52 support, such as
Windows or macOS. The GUI or system way of accessing the clipboard
is used instead, meaning |v:clipmethod| will be set to "none". The
exception to this is the |clipboard-providers| feature, in which if
a clipboard provider is being used, then it will override the existing
clipboard functionality.
term.txt
*osc52-clipboard*
OSC 52 provides terminal-mediated access to the clipboard, including over
SSH. See |clipboard-osc52|.
*xterm-command-server*
When the X-server clipboard is available, the command server described in
|x11-clientserver| can be enabled with the --servername command line argument.
*+clipboard* |clipboard| support compiled-in
*+clipboard_working* |clipboard| support compiled-in and working
*+clipboard_provider* |clipboard-providers| support compiled-in
*+osc52* OSC 52 terminal clipboard support compiled-in
DA1 and XTGETTCAP Ms is supported in regular builds.
In my draft for regular builds it is thus with timeout on reading:
long timeout = term_osc52_is_ssh() ? 250L : 100L;
250ms over ssh, 100ms on regular PC.
(non-blocking btw)
In my testing 10MB clipboard on a Ryzen 7900 finishes as fast as 31ms, quite impressive.
head -c 10M /dev/zero | tr '\0' x
Thus it is also extremely unlikely to fail unless OOM, all-core workload, or over ssh.
It is more likely that a wayland or x11 connection will trip requiring :wlrestore, :xrestore in my experience.
I don't think there are reliable probes into system loadavg that can scale with loadavg, nor do I think network provides a similar probe of performance, however one could scale with the highest recorded timeout over a flaky ssh connection - always expecting output on the other side.
The way it can handle large clipboards, is that it knows as soon as it receives first byte, that there is actually coming data.
I am biased to sensible defaults, basically no configuration and scaling timeout if done correctly.
For errors/warning I am considering if these are sufficient for regular build.
*W23*
When you are yanking into the "* or "+ register and Vim cannot establish a
connection to the X11 selection (or clipboard), it will use register 0 and
output a warning:
Warning: Clipboard register not available, using register 0 ~
Note: This also applies to the Wayland clipboard feature as well.
*W24*
Vim comes in different flavors, from a tiny build, that just tries to be
compatible to original Vi, to enhanced builds which include many improvements
(like a GUI). However, on servers and embedded systems, Vim is typically
compiled without clipboard support, since this feature requires X11 libraries
to be present. Check the ":version" output for the flag |+clipboard| or
-clipboard. The former means clipboard support is present while the latter
means your Vim does not contain clipboard support.
In the case when you are trying to access the "* or "+ register and Vim has
no clipboard support, you will see this warning:
Warning: Clipboard register not available. See :h W24~
If you have a vim with no clipboard support but would like to use the
clipboard, try to install a more enhanced Vim package like vim-enhanced or
vim-gtk3 (the gui packages usually also come with a terminal Vim that has
clipboard support included).
https://github.com/vim/vim/pull/20896
(14 files)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
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.![]()
I don't see any code integrating this with clipmethod option. Is that planned?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
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.![]()
I don't see any code integrating this with
clipmethodoption. Is that planned?
I have it, I was switching pc a lot at the time due to warranty of part.
So yes, clipmethod, and provider is impl, I just have not grabbed it from alternative pc yet.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
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.![]()