I connect my server(centos 7) with putty, and run vim in byobu.
Now I have 2 windows in byobu, and two files, a.py in window-1 and b.py in window-2.
I tried copy some text from a.py to b.py, but ran into some problems.
If I follow steps below, it works fine:
STEP1: In window-1, open a.py, press yy, then quit with :wq
STEP2: In window-2, open b.py, press p.
But if I keep a.py, and b.py open at first , or doest quit a.py after yy, paste fails.
It seems quite odd, did missed anything?
I have set clipboard=unnamedplus in .vimrc, and have +clipboard in vim --version, my vim version is 8.2.1438.
You are able to paste across Vim sessions because of the [viminfo] file. By default, Vim stores the contents of non-empty registers (including the default register) into the viminfo file. That's why when you put (with p) right after you start Vim, you get the contents you last yanked (with yy) before you quit Vim last time.
The viminfo file is written right before Vim quits, and it's read during Vim initialization. That's why this won't work automatically if you start the second instance of Vim before you quit the first instance. Then the viminfo file will be read too early by the second instance (or written too late by the first instance) to allow you to put the yanked text across instances.
You can explicitly write the viminfo file with the :wviminfo or wv command. And you can explicitly read it with the :rviminfo or :rv command. So you could use these two commands in the two separate instances to transfer the register information through the viminfo file without having to quit them.
I have set clipboard=unnamedplus in .vimrc, and have +clipboard in vim --version.
If you're using the X11 clipboard integration, you could use that to share copied contents between Vim instances. Note that setting the 'clipboard' option only affects yanks, so to put from the clipboard register you'd have to use "+p.
But this assumes you have a valid X11 server to connect to, which is quite unlikely in your situation. First, since you're connecting through SSH using PuTTY, you would need to use SSH forwarding to export an X11 server from your client. Since you're using PuTTY, I'm assuming you're on a Windows box, which doesn't really run X11 by default, so you'd have to install one and run it (easier said than done.) Also, since you're running Byobu, you will also have trouble reconnecting to an existing Byobu session, which will quite likely be pointing at an invalid X11 server, using the connection information at the time the Byobu session was created, which may no longer match the new X11 forwarding connection information of the new SSH session... It'spossible to make this all work, but if you want my opinion, it's probably too much trouble, especially for this particular use case of two Vim instances in the same remote box.
Related
Have been enjoying tmux + vim these days, except one problem I cannot resolve every time.
It's a clipboard failure easy to reproduce. Vim's "+y "+p, copy to or paste from clipboard, work well if I create a new tmux session and keep using it either on Linux machine or via ssh (I use MobaXterm which supports X11 forwarding) from Windows. But copy and paste will surely stop working after I switch from one side to the other.
I tried to search but cannot find an answer but maybe I used wrong keywords. Any tip would be appreciated.
This is most likely related to your DISPLAY environment variable.
When you run tmux locally on your Linux machine, it's going to set DISPLAY to the default, most likely :0. This tells X11 programs to use your local X server. The Vim clipboard integration uses that X server for clipboard storage with the + register (in your config, based on your question; it could also use the * register, based on what Vim's clipboard option is set to).
When you SSH in with X11 forwarding, DISPLAY will be set to a virtual server, representing the forwarded connection--most likely :10.0 or localhost:10.0.
When you start tmux, it will use whatever DISPLAY is set to when it's initially started. If you detach and later reattach from the other machine, tmux won't automatically change DISPLAY. So if you initially start your tmux session from Linux, and then later SSH in from Windows and reattach the session, tmux (and the Vim running inside it) will still be using the Linux display.
One option is to quit Vim, do export DISPLAY=:0 (or DISPLAY=:10.0 as appropriate), and restart Vim. Note that you'll have to do this in each shell you have open, and if you open a new window/pane, it will still inherit the parent tmux session's DISPLAY setting.
Another option is to change the environment variable inside Vim, so that you don't have to restart Vim. You can do this via :let $DISPLAY="whatever".
There may be a way to change the tmux session's DISPLAY value at runtime, but I don't know how to do that. If you could figure a way out, you could probably automate it via a wrapper around tmux attach. This answer to a tmux question might help, but I just do one of the above.
I'm still looking for a better solution to this as well, but I found a bit of a workaround.
Save your vim session with :mksession
Exit with :qall
Reload the vim session with vim -S
When vim starts back up the clipboard integration works again.
Just like bydsky says. After your reattach Tmux session with an old running vim. Just run :xrestore Ex command in vim to restore X11 connection.
In Vim,
I can open Vim Ex command Window with q:
It seems to me all the commands are not shared in other instance of Vim.
e.g. I have other Vim instance in a second console.
I'm wondering whether I can share all the Ex commands that I have typed for last ten days
No, command history is not shared. Histories (as well as marks, jumps, opened files) are stored in a viminfo file. The contents are written when quitting Vim, and read during startup.
But (and here comes the interesting part), you can manually trigger these with the :rv[iminfo] and :wv[iminfo] commands. So, first execute :wv in the one Vim instance to export its history, then import via :rv in the second instance. This could even be automated via :autocmds.
I work on multiple MAC OS X systems, which do not save changes after log out. As you know VIM is on every new mac, just type in vim in the terminal. I always bring my vimrc file with me, and the problem is that every single time I start vim i have to load it with :so command.
I want to use the fact that vim is available on every unix, but I also want to take advantage of the nifty integration with the terminal for doing quick tests, I just switch back to the terminal, but for that I need to close vim. When I reopen it, I again have to load the vimrc. And I am a newb, I don't even have plugins yet...
I want to keep the integration with the terminal and only develop a super quick way of introducing my changes to vim. Think of the conditions as if though you are sitting on newly installed operating system.
Thanks !
Not directly to your question, but you can always invoke vim with -u, which will let you specify your vimrc file instead of launching vim and then running :so.
The default location for your .vimrc file is ~/.vimrc (on the mac, ~ is /Users/_you_, eg /Users/matt). If you can write your file there, it will be loaded when vim starts up every time.
The system vimrc file on the mac is at /usr/share/vim/vimrc, but it sounds like these systems are not under your control, so you won't be able to write that file. Have a look at: How can I override ~/.vim and ~/.vimrc paths (but no others) in vim?, which uses the -u option to change the path vim looks for plugins under. But, in all cases, you must either be able to write your .vimrc into your home directory (which it sounds like your system does not permit) or specify the path to it at runtime (as with the command-line option I mention above, or with the normal command :so which you're currently using).
Depending on the kind of testing you need to do, you can always run shell commands within vim, by using the ! in normal mode. For instance, I frequently make changes to a python file in a buffer, and then (in normal mode) run !nosetests within vim—that writes terminal output into a temporary buffer at the bottom, and doesn't require me to leave or suspend vim. I can review the output, and any key-press takes me back to my buffer.
I don't have any experience with Mac-Os terminal. However I think if you could cp your .vimrc file to your home directory. everytime you start vim, vim will load the .vimrc file from your home directory.
If you want to swtich back to terminal from vim to do some testing/execute some commands and back to vim. you could consider to:
open multiple terminal windows
try something like screen or tmux. personaly I am using tmux, and it's very nice.
try Conque Shell plugin: http://www.vim.org/scripts/script.php?script_id=2771 I have this plugin installed too.
type Ctrl-z in vim to back to terminal
If you want to sync your .vimrc on different machines, you could put your .vimrc file in
a scm repository like gitHub, bitbucket... (I perfer this option, since you could have different branches for different settings)
dropbox
I hope this helps.
How is it possible that your changes are not saved after you log out? What would be the point of such a machine? An internet kiosk in an airport? Do you log as a user without a "home" directory?
If you have a "home" directory, just create a blank ~/.vimrc and put your settings there.
If you don't have a "home" directory but you are able to write somewhere else, create a blank vimrc file where you can, write your settings there and learn this command by heart:
$ vim -u /path/to/your/vimrc
If you don't have a "home" directory and you are really sure that you can't save anything on these machines, put your settings in a file somewhere online, preferably a place under your control, and learn this command by heart:
$ vim -u http://domain.name/yourvimrc
If you are lucky, the command you use will be remembered by your shell for you and it will be easy to issue it again without much typing.
For running your tests, you can either:
Hit <C-z> to suspend Vim. You are back at the prompt from where you started Vim and you can do your thing. Type $ fg to go back to Vim.
Type :sh to launch a new shell from the current directory. To go back to Vim, type $ exit.
I'd like to move the current tab into a new (visual/real) window in MacVim.
It's probably difficult, as:
there is nothing in the vim help and only very few - not helpful - hits on google
MacVim does not support it (link, 2009)
So I am wondering if someone has found a way to achieve this?
The closest I think you can come is using mksession
This will have several drawbacks (like, initially the secondary session will open a few more buffers than ultimately desired).
However, it will preserve your mappings, settings, history, window layout (if you had multiple windows inside the current tab, they will all get cloned).
If this idea tickles your fancy, you could look at creating a script that will filter parts out of the session file (which is Yust Another Vim Text Script)
:mksession! $HOME/detach.vim
:tabclose
:silent! !gvim remote --servername Detach -nR +'silent! source H:\detach.vim' +tabonly
save all current windows, mappings, settings (:he mksession)
close the tab we are about to detach
clone the session (detach.vim) into a remote vim
:silent! (try not to talk too much)
!gvim remote --servername Detach; launch a new remote Vim server if it doesn't yet exist, or talk to the existing server named Detach
-nR TODO Fix This is here to avoid the use of swapfiles (because I found no way to suppress the dreaded ATTENTION messages[1]). However, this may be unsafe advice depending on your situation, which is why I also include -R for read-only mode
+'silent! source H:\detach.vim' +tabonly -- In the remote vim, source the session to clone, and keep only the active tab (that was already closed in step 1.)
A little rough around the edges, for sure, but quite close to what you intended, I feel.
If you are comfortable, you can drop the -nR flags and just click through a few annoying swapfile attention messages (keyboard: Q).
[1] :he ATTENTION
Post-scripts:
on windows you might want to use :silent! !start /b gvim .... in case you have terminal windows sticking around
also on windows, you might get annoying behaviour if the resulting gvim window is too small. The :simalt ~x sequence is one hacky way to maximize the window (assuming English UI, because x is the accelerator for Maximize)
as icing on the cake, vim 7.3 has 'persistent undo'. See e.g. :se undofile
I don't think this is possible because, when you open a new instance of (g)vim you don't have access to the undo-history of the previous vim instance. All you can do is (in command mode):
:!gvim %
It will open the current file in a new instance of gvim. At least this is all I could think of. I may be wrong
I have three monitors.
I normally run one maximized xterm on each monitor, attached to the same GNU screen session.
Can a similar model be used for vim? Is it possible to have three vims running, all sharing the same "vim session":
Each vim window showing a different vim tab
vim settings shared between all windows
Not getting the "Swap file ... already exists!" error message if I open the same file on two tabs.
I have a working solution where two vim instances communicate.
http://github.com/codeape2/vim-multiple-monitors
It uses the SwapExists autocmd to instruct the other instance to open a file if an existing swap file is detected.
You can use vim under screen.
$ screen
$ vim
# on another terminal
$ screen -x
# the same vim screen
If your terminal emulator supports tabbing (e.g. gnome-terminal), you can use it as a tabbing (IMHO, gnome-terminals' tabbing support is better than vim's own, except perhaps you can't copy and paste among different vim sessions, however you can instead use the system copy-paste buffer: "+y and "+p).
This does not work if you're using gvim though.
No, a Vim instance is limited to a single application window on your desktop. The different Vim instances have independent sessions.
In addition, be aware that if you open the same file in two different Vim instances, not only do you get the 'Swap file exists' message, but the two instances do not share a buffer, so changes made in one are independent of the other.
If a changed file is saved in one instance you will get a message when you return to the file in another Vim instance that 'the file has changed since editing started' and asking you if you want to reload the file (which would load changes as saved by the other instance, disregarding any changes you had made in the current instance).
Neovim is a project that aim to give vim attach/detach feature like tmux.
This feature isn't yet implemented (june 19th 2015), but this may come soon.
There is many other core features for this project that you can see at neovim.io.
:set noswapfile
:set autoread
Buffers aren't shared this way but vim reads file changes automatically if you save it. And you don't get that 'Swap file exists' message.