Why should I use tmux when iterm2 has split panes?
I have never used tmux, and want to know if there are advantages to using that in my workflow instead of the split pane features iterm2 has.
I really like the dimming of inactive windows that iTerm2 split panes offers. Does tmux do something similar?
What are the advantages/disadvantages of each?
There is another advantage of tmux: what happens if you accidentally close iterm2? If you do it really by accident, you want to reopen everything again. With tmux it is normally as simple as reattaching session without losing anything. Most terminal emulators send SIGHUP to all children which terminates them by default and thus you lose unsaved data (at least, shell and vim command history and other data stored in viminfo) and running processes and thus reopening means rerunning everything.
iTerm2 can use tmux for it's split panes. Personally, I'm used to tmux by itself at this point, so I've not leveraged this ability extensively - but if you are used to iTerm2 split panes, you can get the benefits of tmux (mostly screen-like session saving) with the iTerm aesthetics.
https://gitlab.com/gnachman/iterm2/wikis/TmuxIntegration
My approach (not based on any particular insight) is to use iTerm tabs and panes to separate servers, and screen / tmux on the server to persist sessions.
I don't often have anything of importance running locally, but often do remotely.
Never used iterm2, however I have played with tmux a little and there are several articles about using tmux and vim together. These articles show how you can control a tmux session via the tslime plugin, and others, from Vim. What's nice about it is that you can run a command in Vim to compile your files, run unit tests, etc. without every leaving Vim, but you see the command run in the other tmux pane.
Apologies for not being a complete answer, but hopefully it helps point you in the right direction.
LINK: https://joshuadavey.com/2012/01/10/faster-tdd-feedback-with-tmux-tslime-vim-and-turbux/
Related
Is there a way to open a new vim file in basically a new terminal window(urxvt) ?
For example if I am currently in ~/X/Y.txt and I write
vim --new-window(basically the command needed to open a new window) Y.txt
I still want my current urxvt session while opening the Y.txt in a vim-Session.
gvim will open up vim in a GUI (i.e., not in the terminal).
You can use vim's client-server model. Run one instance as a server and edit files with option --remote.
Another solution would be to use terminal multiplexors like GNU screen, tmux or such.
Other variants are: use a terminal with tabs, use gvim.
I highly, highly, strongly recommend downloading NERDTree. It makes your Vim terminal look (relatively, comparatively) similar to a "normal" IDE, with a narrow file-and-folder bar on the left side, and a "main" terminal window taking up the rest of the screen. You use Ctrl+W to navigate back and forth between the two screens. Plus, in the sidebar, you can use normal Vim commands to move up and down. Whoever created that plugin put a lot of work into it.
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.
I'm using tmux with tmuxinator to configure it. I always have different panes open, with two or more editor sessions open and other stuff. Every time I have to close the whole tmux session, because I'm turning off the computer, it takes time, because there are processes active in various tmux panes. So I have to manually quit every Vim instance, because if I just kill the pane containing it, then I will end up having vim swap files.
So, is there a way to quit the whole tmux session (not just detaching it) and automatically closing all the processes running in it?
Executing tmux kill-server kills all the sessions, windows, panes and also all processes running in them. This is the way to completely quit everything related to currently running tmux.
The above will unfortunately not solve the issue with vim swap files - you will still get them.
I solve the swap-file issue by having the following line in .vimrc:
set noswapfile
As you might guess, it disables swap files in vim. If you save files in vim regularly and you have a reliable computer, setting the above option might be perfectly acceptable.
Tmux Resurrect uses obsession.vim and it gives you the ability to save & restore Vim sessions on system reboot.
I have recently been trying out tmux on my server as a replacement for byobu (screen). When I started editing some code on vim, I found it very laggy when I held on to j and k to scroll up and down.
I thought it might be because there was something wrong with my connection but I tried editing the same file on vim without tmux and I found it much more responsive with almost no lag.
So, is there anything I can do to make vim on tmux not lag?
It sounds like you are using tmux over ssh. If so, you may want to give mosh a try. It is built on top of ssh but with many advantages over ssh. One of them is:
Get rid of network lag.
SSH waits for the server's reply before showing you your own typing. That can make for a lousy user interface. Mosh is different: it gives an instant response to typing, deleting, and line editing. It does this adaptively and works even in full-screen programs like emacs and vim. On a bad connection, outstanding predictions are underlined so you won't be misled.
It worked much better than over ssh in my experience.
I often work on a remote machine, and I have the same vim scrolling problem. When you use vim inside tmux and you have multiple panes open at the same time, tmux can't just redraw the part of the screen where vim is running, but it has to redraw a much bigger portion (potentially the entire screen). This increases the number of escape characters that tmux is sending through your connection.
In my case, enabling ssh compression reduced this kind of slowness quite a lot. You can give it a try with:
ssh -C user#host
or put Compression yes into your ~/.ssh/config to make it permanent.
Is there a good project / session manager for vim? A session (or project) is a named lists of files, e.g. "bitonic_sort" could identify files "~/A/bitonic_sort.sk", "~/B/bitonic_sort.smt2", etc.
(rationale) I have a project where I need to edit files from many different locations, and it is too cumbersome to open them manually each time I resume work. (so, it looks like things like nerdtree brought up at this sister question, Favorite (G)Vim plugins/scripts?, won't work). I also need separate sessions (i.e. lists of files) for different projects, not just a recent document list.
After all documents have been loaded as buffers, any enhancements to switching between them is a plus (e.g. start typing a name, and matching documents are displayed). Thanks in advance.
Vim has built-in session manager. To save your current session use:
:mks session1.vim
This basically create a Vim script named session1.vim, which will restore your opened file if you source it or start Vim like this:
vim -S session1.vim
To overwrite your saved sessions, use :mks! your_saved_session.vim. Combine with a custom key map and this will be the solution. For more about Vim session read :help :mks. Vim also has views manager which is quite similar. Read more from: :help :mkview
For switching between buffers, you can use FuzzyFinder; but I prefer this key map:
nmap <C-tab> :bn<CR>
imap <C-tab> <ESC>:bn<CR>i
Add it to .vimrc and I can use Ctrl + Tab to switch between buffers just like Firefox tabs. Hope this help.
I'm not sure exactly what you're asking for... but if you want to turn on tab-completion when opening files in vim, add this to your ~/.vimrc:
" Auto-complete file names after <TAB> like bash does.
set wildmode=longest,list
set wildignore=.svn,CVS,*.swp
Also, take a look at screen. From the man page:
When screen is called, it creates a single window with a shell in it (or the specified command) and
then gets out of your way so that you can use the program as you normally would. Then, at any time,
you can create new (full-screen) windows with other programs in them (including more shells), kill
existing windows, view a list of windows, turn output logging on and off, copy-and-paste text between
windows, view the scrollback history, switch between windows in whatever manner you wish, etc. All
windows run their programs completely independent of each other. Programs continue to run when their
window is currently not visible and even when the whole screen session is detached from the user's
terminal. When a program terminates, screen (per default) kills the window that contained it. If
this window was in the foreground, the display switches to the previous window; if none are left,
screen exits.
It's pretty much like having several xterms open, except unlike graphical xterms you can access your screen session if you access your machine remotely (e.g. by sshing to it). You could leave up several different instances of vim in separate screens with all the files you want open, and just never exit them.
The very basic setup I use is one vim window, one compile window, and one testing/debugging window.
And since we're talking about vim, check out this post: Post your Vim config. Lots of cool tweaks and spiffy stuff in there.
You can try the vim-workspace plugin, its session management features are automated and relatively simple (compared to vim-session): https://github.com/thaerkh/vim-workspace