One of the big questions I have for myself, which I have yet to feel comfortable answering, is where should I be doing my splits and terminals, in NeoVim or in Tmux?
Both vim and tmux will split windows, and switch between processes. NeoVim even has a terminal built-in if I wanted to use it. I used to open a new file in nvim in each tmux window, but recently I’ve been using one running nvim instance and switching between buffers when I need to change files.
What is your workflow experiences with switching windows and managing splits with vim and tmux?
Not quite the same, but perhaps related: in Emacs, there are both the concepts of “frames” (which are actual windows in your window manager) and “windows” (which are panes within the Emacs frame). They are all part of one Emacs instance, so I can still copy/paste between them, run commands in one that affects the other, and so on.
I have long debated whether to let my window manager do the window managing (which is philosophically pleasing) or do it in Emacs (which is more convenient from an initial configuration perspective as well as on various OSes).
Currently, I use both. What generally decides it is some sort of vague notion of “context”, i.e. “if I move window A from this monitor to the other, do I also want B to move with it and them to retain the same relative configuration?” If the answer is yes, then I let Emacs manage those windows. If no, I tear B off as a separate frame.
That said, if you also use window manager windows as a third layer to the hierarchy, then all of this is probably already obvious to you.
Fair question :) I’m by no means a master of this workflows. I don’t do any advanced things.
Here is my setup:
I’ve multiple machines where I share same .vimrc and I check in vim sessions (mks) to git repo. So I try to emulate same environment for each machine. Mostly sessions fail to regenerate though.
I have one tmux session per project.
Within that session I have 2-3 windows. I don’t use splits of tmux for the reasons you have listed.
One window is for vim for sure
One window for backend server logs
(optional) One window for frontend server logs - I don’t really develop be+fe at the same time. Too much distraction
(optional) One window for pyconsole/git/random trials etc.
(optional) One window for README.md notes about the project.
tmux does a lot if you have a low power machine while vim struggles to render depending on the terminal emulator.
eg. My travel laptop is a $140 chromebook. It has really hard time if I have multiple vim splits on the same buffer and try to scroll. So I utilize vim tabs (gt gT), after editing, ctrl+b+n to my tmux window where I can see the outcome of the code.
Thanks for the reply. I did not know about vim sessions. I write a little shell script of tmux commands on a per project basis. It sets my env vars, creates tmux windows, and renames windows to be useful.
nice; could you share the shell script if it’s ok :)
I was looking for a simple solution for this rather than black box plugins.
Sure. This is a good example: https://github.com/UkiahSmith/tmux-playground/blob/master/note-tmux.sh
Can you yank and paste lines between nvim buffers in different tmux panes?
Sort of. I setup nvim to yank to macOS’s system buffer, which I can then paste into another nvim instance in a different tmux window. So it is not two nvims sharing a clipboard, but it works for me.
vnoremap <Leader>y "*y
Collapsing the number of registers I can save to to 1 has always felt like giving up too much power.
What I do instead is maintain tmux panes for other windows but otherwise keep Vim windows within a single pane – and then use a single keyboard shortcut to navigate transparently between them all.
Very useful cheat sheet, thanks!
ctrl + b % => Split pane vertically
ctrl + b % => Split pane vertically
ouch, Shift+5 sounds painful, and Ctrl+b isn’t that convenient either. I have Ctrl+q v to split vertically, and Ctrl+q s to split horizontally.
(Of course the downside is that I sometimes hit Ctrl+q in non-terminal windows and that causes the app to quit :D)
tbh that’s more intuitive than “ and %.
However, I’d refrain myself to use ctrl+q for the reason you mentioned :)