mjhjmtu

I am a little embarrassed to ask this question, but this topic seems to be particularly difficult to search.

On Linux systems I almost exclusively use the terminal and access the systems (from macOS most often) using SSH through a terminal emulator.

In the general sense, copying and pasting code snippets and errors from logs, etc. is a tricky problem to traverse the buffer across systems, when a terminal multiplexer is involved, and this is usually achieved by copying via the terminal emulator's own selection feature and use the client's OS's paste buffer. This question is NOT ABOUT THAT.

My issue is when I have a large number of vim instances open on a single Linux server. I am in runlevel 3 and do not run a GUI. There is no xclip available to me, mainly because X is not installed.

When I am in this workflow I find the need to yank parts of files and paste them in other vims on the same remove box. Vim's builtin + and * copy/paste buffers do not work. (the clipboard compile option in vim is not enabled on these systems)

However, what works is if I yank some text in one vim instance, quit it, and open another vim instance, then pasting works. So something about exiting vim persists the buffer somewhere. I think that if I can just have whatever this system is work in realtime without having to close vims, that would be great. I would like to avoid having to layer a bind on yanks and deletes to implement my own yank/paste implementation.

This is the .viminfo file (:h viminfo).

When you exit vim it writes out the current state, such as command history and register values to that file. When it starts, it reads the file and restores whatever state it describes. That means that successive vim sessions (appear to) share some state, but concurrent ones don't.

You can forcibly re-read the viminfo file with the :rv/:rviminfo command, and manually write it out with :wv. So y :wv in one editor, and :rv p in the other will work, but there will be side effects: all your register values and command history may be reset, and quite a lot of other things, which may or may not matter to you.

That can also be an advantage: you can use the full range of registers to get multiple copy buffers between editors, which the system clipboard doesn't provide. On the other hand, it's not terribly convenient unless you rebind y to do this automatically, and p you probably don't want to read the file every time. I have read/write viminfo bound to leader commands, but that only saves me one keypress (and it sounds like you'd use it more often).

There are some other approaches you could use, like paging out manually to a specific file yourself, which would avoid the side effects. It doesn't sound like you want that, but it's an option. There are also plugins that do more or less of what you're looking for, and the sessions system as well. They aren't direct answers to your question but they may inform where you want to end up.

As promised:

The linux specific scripting (my $HOME/util is in my $PATH):

~/util ❯❯❯ cat linux_pb/pbcopy ✘ 130 master b28083b $ ◼
#!/bin/bash

# pbcopy impl for linux!
# pipe the stdin to a file using cat. Not using bash builtins due to concerns
# about NULs.

FILE="$HOME/.clipboard"
touch $FILE
chmod 600 $FILE
cat > $FILE
~/util ❯❯❯ cat linux_pb/pbpaste master b28083b $ ◼
#!/bin/bash

# pbpaste impl for linux!
# just use the content of the file.

cat ~/.clipboard

The vim bindings:

vnoremap <silent> <Leader>y :w !pbcopy<CR><CR>
" the leader y works like normal yy (but for my clipboard)
nnoremap <silent> <Leader>y :.w !pbcopy<CR><CR>
nnoremap <Leader>p :read !pbpaste<CR>

The idempotent shell alias script (I source this alias script from bash and zsh):

if [ "$(uname)" = Linux ] && ! [[ "$PATH" = *"/linux_pb"* ]]; then
 PATH="$PATH:$HOME/util/linux_pb"
fi

I will likely flesh out the Linux configuration even more when I start to use an actual linux with X, so that I may also take advantage of its paste buffer also. It would require some mechanism to create pbcopy and pbpaste programs similar to this.

The approach is one of uniformity at the program level, so Vim can leverage the functionality exactly like I am now able to from the shell.