toggleterm.nvim VS tmux

akinsho/toggleterm.nvim: A neovim lua plugin to help easily manage multiple terminal windows.

As a data point, I'd like to chime in here. I have been a 15 year user of tmux (and screen before that) and never thought I'd change my development habits. Over the holidays I decided I would do one of those once-every-five-years upgrades to my vim setup as I had accrued dozens of vendored plugins in normal vim and wanted to see what the big deal with neovim was.

I bit the bullet and evaluated some of the "distributions" (AstroNvim and kickstarter) and played around with all the new lua plugins that I had never thought I needed (why use telescope when FZF-vim worked so well?).

Anyways, after a month of tweaking and absorbing, I found myself running Neovide only, and doing something I never thought I'd see, running tmux from within neovim/neovide. I think this only works (for me) because of session management (there are half a dozen plugins for handling quickly changing 'workspaces') and because the built-in terminal (with a very useful plugin called toggleterm: https://github.com/akinsho/toggleterm.nvim) works so well.

I have not stopped using tmux and layouts, and it sits in another fullscreen iterm2 workspace, but I find that I now spend 90% of my time using a fullscreen neovide and summoning/toggling tmux momentarily for running commands.

Of course, the caveat here is that my preferred mode of operation is being fullscreen as often as possible. I think if your preferred mode of operation is to always see splits then running neovim from the terminal within tmux is still the way to go.

As for why I like neovide? I find the animations, when tweaked to be less 'cool' are extremely useful to see where the cursor jumps to. I am also a huge fan of the fact that I can finally use 'linespace' to put some space between my lines of code -- it is an aesthetic I didn't realize I wanted.

For splitting the terminal you could try either toggleterm or tmux. If you want to send things from one tmux pane to another, then you can use slime. For a toggle-able filetree, you can use nvim tree.

I just found toggleterm which feels awesome. Pretty much exactly what I was looking for to use with Alacritty but even better since its integrated into the rest of my Neovim workflow.

I saw this plugin that tells me how to do it, however I got confused after I added "require("toggleterm").setup({})" in the lazy.lua file and installed the package as well using the Lazy command

I tried toggleterm but I wasn't successful.

And I never really got into Gitsigns or vim-fugitive. Lots of people love them, so I'm sure they're great, but I'm happy opening a floating terminal with Toggleterm and using Lazygit.

I agree with u/Bamseg, but you can get what you want using toggleterm.nvim BUT NOT IN FLOAT.

I use gitsigns for linewise operations (blame, reset, etc), and a floating terminal (toggleterm) for everything else. flatten.nvim also helps with nested nvim instances.

but I ended up finding a good enough workaround by using Lazygit through Toggleterm.

Instead of opening a bunch of terminal tabs or windows, I switched to tmux. It lets me manage multiple sessions in one window, split panes, and run different services side by side. It’s lightweight, keyboard-driven, and fits perfectly with NeoVim.

If you've used terminal multiplexer in command line, you know tmux is cool! If you haven't, you really should use something like tmux, especially if you SSH into remote servers often!

Additionally, I integrate several CLI tools into my work flow, such as lazygit for streamlined Git operations, yazi as a terminal file manager, tmux for session management, and lazydocker for handling Docker containers efficiently.

3. Running the App Entirely in Docker (with Persistent Data): For devs who prefer a fully containerized development environment, they can now the backend and database in Docker (my personal favorite method). This approach minimizes dependency conflicts and leverages Docker-specific PostgreSQL tools. To ensure persistent data storage, similar to a locally hosted PostgreSQL database, I configured Docker volumes. With Docker volumes, this enabled both staff developers and contributors to fully containerize the application without needing to re-populate the database with each new container. Additionally, this streamlined my pull request workflow as a maintainer, as I no longer needed to manually populate the database from a forked branch when reviewing complex pull requests locally. Of course, there are caveats to this method, forked pull request tests run on my machine using Docker volumes can alter my local database, but I quickly realized I could navigate this using tmux multiplexers or docker-compose.override.yml files (that is for a future blog post).

When systemd broke tmux (which isn't a Linux project, but ported from OpenBSD) and instead of reverting or fixing their own bug, systemd devs went to the OpenBSD folks and asked them to work around the bug that they caused themselves. This is ragebait-level insolence:

https://github.com/tmux/tmux/issues/428

This. To add some words why this is important:

Given the remote-first container-based world we're heading towards, decoupling UI (terminal emulator) from its state (tmux, code-server) is a great design decision, which I think will ultimately define what the "next generation" of terminal emulators is. Imagine being able to open tabs directly on remote host, reconnect without losing state, etc, all while using native UI (so Cmd+T to open new tab, Cmd+F to search, etc). Productivity game changer, which currently only the iTerm2 users can fully enjoy.

Ptyxis (putting its state in running containers), WezTerm (native handling of ssh sessions) and VSCode's terminal (starting a proprietary code-server binary and connecting to its TCP port) have reached some of this functionality, but in their design they need some out-of-band mechanisms to do their magic, ultimately limiting the scenarios they can handle.

Meanwhile tmux -CC [0] and ht [1] are sending both their control channel and data channel over the opened terminal itself (in-band), making them flexible enough to support any configuration. Something complex like `ssh jumpbox -- ssh prod -- podman exec -it prod /bin/bash -- tmux -CC` should just work.

[0] https://github.com/tmux/tmux/wiki/Control-Mode

[1] https://github.com/andyk/ht

What is tmux?

This also gave me the chance to learn how to use Tmux. Best tool I've learned in a while.

To keep it running in the background we can use tmux