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.
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.
When I'm not in insert mode and I'm navigating around my file with the motion keys (hjkl etc), the keys often appear in the buffer (illustrated below). I can observe this effect pretty readily in tmux, but it doesn't seem to happen without. If I run :!reset in vim the buffer returns to normal, but it doesn't stay that way for long. I'm not sure why this is happening and google yielded nothing. Halp?
Edit: It seems just a simple :e will fix the problem, too.
I experience the same thing. A few extra observations:
it only seems to happen when I hold down a motion key like j or k, causing rapid repeats
it happens both in and outside of tmux, but much more often in tmux
it happens much more often since I enabled vim-go's go_auto_sameids, which I believe is making a call to an external program (guru) for every cursor movement
This leads me to assume that it's a timing issue in vim that is exacerbated by latency added by things like tmux and/or plugins.
(Using gnome terminal; $TERM is screen-256color in tmux and xterm-256color outside)
I think this was alluded to on the tmux mailing list recently. Try decreasing the value of the escape-time parameter in tmux, so that tmux more quickly sends the escape character to vim to return to command mode, rather than waiting for more characters in an escape sequence. The default value is 500ms, so try something smaller, like 50.
In .tmux.conf:
set-option -g escape-time 50
I use two monitors in my development workflow, one is a fullscreen vim session for editing and the other is a fullscreen terminal where I run make && ./test to show results. Fairly often I find myself opening a bunch of other windows in the background (browers, more shells etc). I don't like this for a few reasons:
I don't like having to remember how many times I have to hit tab before I get my make window.
There's no strong visual feedback in Ubuntu for which window is currently in focus. I could probably do something about that but that's a separate problem.
To be honest I'm lazy, and :w alt-tab up-arrow enter alt-tab is far too many keystrokes.
I think a good solution might be to have a vim command that runs make && ./test in the other window, but I can't think of how to do this. I could write a server/client script that waits from some notification from vim then runs the command but it really seems like there should be a simpler solution. Any thoughts?
Thanks to Jim's comment for getting me started. This is what I'm doing now:
On the first monitor: tmux new-session -s dev (creates a new tmux session named dev)
On the second monitor: tmux new -t dev (connects to that new session)
On the second monitor: Ctrl-b + c (creates a new window)
I forked vimux and wrote functions to send commands to another window. So now in vim I can use :call VimuxRunCommandWin("make && ./test").
And I think that's probably enough procrastination for one day...
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/
When using vi it sometimes echoes keypresses to the screen. For example, if I press escape, it will show ^[ on the screen. The actual characters don't get written to the file, because if I go to another place in the file and come back, the characters aren't there. Still, it's confusing when this happens, especially if the characters appear where there's text.
I also have gvim installed. It never happens there, but it happens in all the various types of vi that run in a terminal.
Why does this happen, and how can it be fixed?
It's okay when you are working on slow connection.
It also happened to me, when I used vim/vi on remote machine over slow connection. It's because the slow connection extends the internal speed vim responds to your keystrokes. For me, nothing harmful but it's slow, and gives exception to eyes. At least VI is designed in this kind of condition, it can handle slow connection very well.
This doesn't really help you fix the problem, but if it's just noise in the terminal, you could use the :redr[aw]! command to clean up your screen.