Show HN: tmux.nvim – turning Neovim into a terminal multiplexer
1–10 of 21 posts
Re: Show HN: tmux.nvim – turning Neovim into a terminal multiplexer
#2While tmux has issues this would likely be the opposite of what I want because now my processes are reliant on vim. There is zellij if you want a fast Rust-based alternative to tmux.
Re: Show HN: tmux.nvim – turning Neovim into a terminal multiplexer
#3While tmux has issues this would likely be the opposite of what I want because now my processes are reliant on vim. There is zellij if you want a fast Rust-based alternative to tmux.
I use dtach to launch console processes with persistence.
I havent switched to neovim yet, but for a lot of my work I have very long running vim sessions that i reconnect to. I find it much nicer having a single system managing my environment than multiple different layers.
Also tmux is a terminal emulator, where-as dtach passes through, and I find a lot less weird color handling & other bugs with dtach.
Re: Show HN: tmux.nvim – turning Neovim into a terminal multiplexer
#4I get that this is under development, but at this point is this really more effective or smoother in terms of workflow than just using standalone neovim and tmux?
Re: Show HN: tmux.nvim – turning Neovim into a terminal multiplexer
#5I currently use tmux and vim all day every day, including as my dev environment (if I'm not in a browser). Are there any advantages to this?
My initial thought is that having vim inside a terminal session is a better organization model than having a terminal session inside of a vim pane, but maybe that's just because it's how I've worked for 20 years so it's what I'm used to.
I know that some vim users prefer to run commands from inside vim. Is that the type of people this project is aimed at?
Re: Show HN: tmux.nvim – turning Neovim into a terminal multiplexer
#6While tmux has issues this would likely be the opposite of what I want because now my processes are reliant on vim. There is zellij if you want a fast Rust-based alternative to tmux.
off topic, but what makes zellij faster than tmux? Are there any benchmarks (I am unable to find any on their site or github page) or is it just because it is written in rust that it is assumed to be fast?
Re: Show HN: tmux.nvim – turning Neovim into a terminal multiplexer
#7nvim inside of tmux is my go-to development environment (i.e. https://matt-w.net/blog/workspace-management/), so I'll definitely need to check this out.
Doesn't support detachable sessions yet, though. That's a core requirement for me, so it'll need to wait for Neovim 0.7.
Re: Show HN: tmux.nvim – turning Neovim into a terminal multiplexer
#8I currently use tmux and vim all day every day, including as my dev environment (if I'm not in a browser). Are there any advantages to this? My initial thought is that having vim inside a terminal session is a better organization model than having a terminal session inside of a vim pane, but maybe that's just because it's how I've worked for 20 years so it's what I'm used to. I know that some vim users prefer to run…
I sometimes try to edit a file in neovim only to be warned that I have the same file open already (in some other tmux window or pane).
I imagine having tmux in vim instead of vim in tmux might resolve that issue for me. I'm curious to try this for that reason.
Re: Show HN: tmux.nvim – turning Neovim into a terminal multiplexer
#9Honest question: I don't question the positive impact nvim had on vim's development and improvement. It really fostered new ideas and was key in pushing parallel module runtime.
Is there a point to switching to nvim now though, with vim 8 available everywhere? What does nvim brings?
Re: Show HN: tmux.nvim – turning Neovim into a terminal multiplexer
#10While tmux has issues this would likely be the opposite of what I want because now my processes are reliant on vim. There is zellij if you want a fast Rust-based alternative to tmux.
off topic, but what makes zellij faster than tmux? Are there any benchmarks (I am unable to find any on their site or github page) or is it just because it is written in rust that it is assumed to be fast?
I'm not suggesting it is faster than tmux, just that is is a fast alternative compared to some of the other alternatives. I'd recommend trying it out.