I've switched from tmux to zellij about 2 monthes, ago, it may have less features than tmux for now but it certainly does all i need, in most case better than tmux. It is much more user friendly and usable imo.
Frankly i've spent too much time in the past fiddling with complex confs and tools which expect the user to spent days figuring out a conf which work for them. Then if you don't use the tool for 1 month, or simply don't edit the conf for a big while you've forgotten half of it.
Zellij has a conf file, it took me a bit of time to tweak it at first, but i know I can understand it in a pinch. Same thing for actually using it, it's mostly discoverable.
And most importantly, it is very clear that simplicity and predictability are big priorities. It shows everywhere in the project, I totally vouch this approach and tend to do the same thing on my work projects. I know from experience than understanding your user's needs and getting out of your way to make their life easy by not having to think about how the implementation is done is really much harder that just making a tool configurable and extensible...
I've never quite understood why TUIs on *nix systems seem so downright unfriendly compared to TUIs on ye olde MS-DOS systems. Some of them are excusable, sure. vi predates consumer TUIs, and vim clones it. Emacs at least has a menu bar, even if there's no on-screen indication that F10 activates it.
But tmux was created in 2007. I can think of no reason for it to have such an obtuse UI other than "they're just like that on *nix". Would at be so much to ask to at least by default have a "press C-b ? for help" on screen?
It has the look but not the feel. Norton Commander was extremely fast on a 4.77mhz 8088 (basically an 8 bit processor pretending to be 16 bit. It took two clock cycles to move 16 bits across the bus). It's no comparison between those old DOS apps written in ASM that really optimized every instruction for a specific architecture. They felt 100x faster and more immediate than modern computers.
tmux is not entirely dissimilar to GNU Screen which uses `C-a` rather than `C-b` as its prefix key. That conceptual lineage may explain some of the UI choices.
In case you were curious where the name comes from:
Zellij (Arabic: الزليج, romanized: zillīj; also spelled zillij or zellige) is a style of mosaic tilework made from individually hand-chiseled tile pieces.
Happy to see it, but unlike others in this thread I have no issue at all with Tmux.
The way people are reacting to zellij is how I reacted going from screen to tmux. It was so much easier to understand and quickly get started doing advanced things in, compared to screen.
I switched and then went back to tmux after a week. It just worked. I will probably try again o six months, as it was def*nitely faster, it just takes me some time to get used to new paradigms
I’m always surprised to see that there are so many professional developers who never tried tmux and don’t really understand why a terminal multiplexer would be useful. I’m in tmux all day and it’s one of the first things I install on any box. I’ll check out Zellij, but it’s a high bar for me to switch.
My terminal emulator (Konsole) has tabs. It also has tiling features I've never taken the habit to use. It has infinite history and allows me to easily select and copy paste many lines. It has a perfect scrolling behavior: it automatically scrolls, but stops auto scrolling if I scrolled a bit up. I'm used to its keyboard shortcuts to switch tabs. My window manager (KWin) also has tiling-like features when I need to see several terminal sessions at the same time.
I use screen when I need to be able to leave and rejoin later. I almost never need to restore several remote terminal sessions at once, and when I do, I'm happy to just ssh several times.
I feel like my use case is completely covered by the terminal emulator and the WM which are incredibly convenient and efficient. I would expect any layer between this efficient / optimized character display and the programs I run can only add latency. I also quickly feel overwhelmed by a screen full of characters. I think I would miss out on convenience by switching to tmux and it's unclear to me what I would gain.
I use the same setup you use Console etc, but still needs tmux in two different settings. The first one is the same as your usage of screen. The second one is when I teach: I prefer to have my notes and examples on my screen and my presentation on the video projector, but that when I'm live coding or demonstrating something to my students, I have to do it on the big screen which is behind me, and my neck doesn't like that at all ; thanks to tmux I can easily have duplicated terminals on both screens :).
> when I'm live coding or demonstrating something to my students, I have to do it on the big screen which is behind me, and my neck doesn't like that at all ; thanks to tmux I can easily have duplicated terminals on both screens :)
Ah, clever :-)
In the theme of duplicated terminals, once, I used screen so we could share a terminal session remotely on the same server with a colleague to work together.
I got some odd reason why i need tmux: I can't use most "modern" terminal emulators because their input latency is awful and playing RTS games for a decade made me too sensitive to input latency. So i'm using xterm which provides no tabbing but with tmux.
Have you tried Konsole? I've read it's actually one of the fastest, probably not more than xterm though and you'd need to be willing to use KDE software.
Same here, I use tilix as my new favourite, it has panes & tabs that are just there without having me to remember a complex combo...
If I'm remote well I do it the old school way with gnu screen!
I tried a few times to see if I could get any advantage using tmux but always revert back to none at all. To me the scrollback that works 'as expected' without having to remember key combos, and also work with the mouse are a key feature!
Using tmux + tmuxp[1] you can load a pre-configured session and execute arbitrary shell commands for the session, window and pane. I use this to set up shells and editors in the correct dirs (and/or hosts), load lang environments, set env vars and source some zsh aliases and functions that I only want per project. The end result is that I can set up my dev environment (shells with different environments, neovim windows, test runner, various linters I don't wannt integrate into nvim) with a single "tmuxp load <project>".
edit: That is just my personal killer feature, obviously having a terminal setup that is consistent cross platform and great for stream processing is a given.
I am with you 100% on this (see my separate comment which mirrors yours almost exactly). I like tmux for one reason: I can disconnect from a remote session and reattach later. If my internet connection is interrupted or or I just need to move to a new location, tmux is awesome for this. Beyond that, I really don't get the appeal of implementing terminal multiplexing at that layer. It's a job that can be done much better by a terminal emulator. ssh even has socket multiplexing built in, if you're inclined to use it, but it's only good for a little bit of a performance boost (quicker connection time by reusing an existing socket).
I use the same - Konsole plus KWin tiling with an extension. I do use Konsole's tiling quite a lot though.
The one big advantage of a multiplexer that I can think of is you can disconnect and reconnect from a session. Not something I really need but might be useful.
Tmux is more keyboard oriented, I guess. For example: I can copy and paste from one pane to another without touching the mouse, which is something I think is not possible with Konsole. (I haven't used Konsole or KDE for many years, so that might've changed).
Tmux is more programmable. You can write scripts to automate stuff, for example setting up a layout, etc. with a degree of freedom that is not possible with Konsole.
You are probably fine with your setup, not trying to convince you ;-)
Personally: I just like fancy TUIs. One of the first things I programmed was mIRC scripts, might be because of that.
Just a suggestion, it's easy to capture command or program output with xsel, just by piping into it, for e.g.: 'ls | grep -i "whatever" | xsel -b'.
It is common for me and I have aliases set up for 'ls=ls -lah', g=grep -i' and 'x=xsel -b', so the actual commandline looks like 'ls | g "whatever" | x'. Then I can paste or redirect the result into something else.
There are probably better command line clipboard managers, but I just happened to settle on xsel, and it seems to work pretty well. That, and using alt and number keys to switch between tabs gets me pretty far with my terminal emulator.
I use tmux when SSH'ing to remote boxes, but when working locally I find native terminal panes and tabs to be a better experience. Does tmux provide anything extra to what wezterm/kitty/iterm2 do?
- a tmux session persists on the remote machine, whereas with direct SSH a disconnect loses what you were doing
- a tmux session can be used by multiple people
- with tmux a single command “tmux attach -t someusefulname” restores the layout and all of the commands used, saving a bunch of time and opportunity for error
- tmux has an API, so you can spawn a fully loaded session from scratch with code, rather than by manually doing things or by having a pre-made session (this is soooo underrated, especially if you make it configurable)
Honestly there comes a point where you just redesign the software and have it run in a more automated fashion anyway, but for the odd job that you have to run from time to time it’s very handy to have tmux as a persistent, shareable, configurable scratch space.
You can use the tmux API or a plugin like tmuxp[1] to load a pre-configured session (including running arbitrary shell commands and setting layout).
Using this you could automatically spawn your ssh connections as nested tmux sessions.
Obviously this brings some complications, namely that you need to set different prefix keys (or double press prefix) and any non-prefix hotkeys always get sent to your local session. Personally I just configure remote tmux to have only prefixed keybinds and never make any complicated layouts on remote sessions so that having to press <inner-prefix> + <key> doesn't get annoying.
Smooth scrollback in a terminal emulator using the mouse/touchpad, with terminal tabs, is way too useful for me to switch to tmux for general use. I use scrollback a lot. Sometimes I search scrollback too, which some terminal emulators do nicely.
If they would just add a tty protocol for good scrollback! :-)
I do use GNU Screen on servers for long-lived sessions. Just because it's more familiar than tmux to me. It's great for persistence, but really annoying to have to use key combos to look through and search the scrollback in Screen sessions, so I tend to log all sessions to files and read the real-time logs with `less -R` and `ripgrep` when I need to look back through session history, even though I could use the Screen interface to do it.
I'm good with letting tiling be a concern of my DE/WM. That's consistent across all the windows I use - I don't have to memorize how tiling works in tmux vs in emacs vs in everything else; I have one setup, I create windows to tile and use tabs to multiplex within tiles. The advantage is that this setup gives me consistent, spacial access to even apps that otherwise won't tile, like Safari or Firefox. All the other advantages of tmux, i.e. that it is programmable etc. are just as true of my WM - I interact with it mostly using scripts I've written, and since this is a local machine I don't care about persistence.
It depends entirely on what you're actually writing!
In some jobs, I always have multiple tmux terminals running. I was about to claim that I have none running right now, but shamefully I have a Mastodon bot that I never productionized running in a tmux on my server.
If you're exclusively a front-end JS developer, it's hard to see how you'd use tmux at all.
Same here, my tmux bindings are hardwired in my brain at this point and switching over would incur a huge drop in productivity at first, not sure I have it in me to switch… floating pane does sound nice though
I use tmux with neovim. Typically I just use neovim's tabbing and splits. However, when I'm running multiple processes such as a psql and a dev server I'll have that in another tmux session, usually split in there.
Additionally, i can ssh into that neovim session if I switch to my laptop, or just leave it open for later without having to :mks!
I switched from Tmux to Zellij ~2 months ago. What I like most about it is the floating panes feature that makes it really easy to create terminals for running stuff in the background without taking up space in the main window.
Exactly my experience. This is the killer feature for me. It helps to not break flow while working on a given task. Also, it’s great that the floating pane is per tab as well so those related background/interactive tasks can be context dependent.
I don’t see what benefit floating windows bring to Tmux workflows.
If I want to run something in background, I just Cmd+number to another window and run it there. Thanks to multiple panes & windows, I can have N things running “in background”, it takes a millisecond to switch to any of them, and I guess if I bother I could even have window tab title reflect the status of the process.
I’ve seen floating windows in Neovim, but I see only one use for them: expanded LSP error messages. Otherwise, I use floaters when they come plugin’s config, but they are more of a nuisance and are tricky to manage without resorting to pointer device.
I was using a similar workflow before switching to Zellij.
The benefit is that you can only use one window for every project instead of 2 or more.
What I usually do is have Vim take up the entire window and use floating terminals for background stuff which can be brought in and out of view with a hot key.
The floating terminals are stacked by default, but they can also be arranged side by side if needed.
I won't claim it to be a huge game-changer for productivity, but its definitely a nicer workflow for me.
I don't really get why you would bring a floating terminal into your "main coding screen" to do something in the background. What problem does it solve compared to just switching to another window, running the command, and and switching back?
Also in tmux you can just attach a existing window as a split to your current window and then pop it out again using aliases/bindings.
Interesting. Tmux also has pane zooming feature (where it will take the entire window until you switch it off) & window/pane browser (prefix + B, I think). They seem to achieve something similar, though I rarely see a need for it.
I keep different Tmux instances for different projects so I get up to 9 windows per project with no overhead.
That is an anti-feature for me, as I don’t see immediately how to switch to the one I need through keyboard, without clicking it. There must be a quick switch of some sort?
Yes of course, you can use keyboard to do everything in Zellij. One thing that eased my transition was the addition of (customizable) Tmux keybindings so that muscle memory was retained.
tmux popups are not first class citizens (eg. at least in current versions they freeze the display behind them, opening a terminal inside one of them is a pain as well as opening multiple ones, not to mention resizing them or rearranging them intelligently)
A killer feature for me is combining floating windows with "zellij run". It allows you to run a command but also re-run the command by pressing enter.
zellij run --floating -- date
This will open a new floating window with the result of the command (`date` in this case) and pressing enter will run it again. I use it for running tests (make some changes, show floating windows, press enter). Depending on your OS you might already have shell aliases such as zrf (run floating) or zr.
Not really but where do you press these? Say I have the editor full screen. Do I switch to a different tab/split/window? In Zellij I press <meta+f>+<enter>. Pressing <meta+f> again will hide the floating window and I'm right back in the editor. I don't use this all the time, sometimes I have a terminal open in a split, but it can be pretty convenient.
I use iTerm in visor mode, so ctrl-~ (tilde) shows my terminal tabs and changes focus to them. Pushing it again hides them and returns focus to the previous app.
Last time me and a coworker tried out Zellij (a few weeks ago), there was noticeable input lag compared to tmux. Used the most recent macOS release, running in alacritty w/ zsh. Anyone else had an experience like that? I think for terminal-based tooling like multiplexers, low latency should be a hard requirement.
I've been consistently using zellij for about 6 months now, and i've not experienced any lag. Using iterm2, so not sure if you're seeing alacritty related issues?
Not input lag but scrolling an editor in fullscreen on a large monitor is kind of laggy for me sometimes. I hope these changes will make a difference (not yet in a stable release).
Of my series of PRs, I suspect the third (i.e. https://github.com/zellij-org/zellij/pull/3043) is most likely to have an effect. But if it does it'd only be as a side effect unfortunately - my focus was on fixing lag with splitting of extremely long lines.
From what I saw while making my changes, that area of the code has a bunch more possible optimisations, but it's 'good enough' for me at this point so I'm not planning to continue pulling at the thread right now. If you wanted to look yourself, I left the script I used for benchmarking and profiling in https://github.com/zellij-org/zellij/issues/2622#issuecommen...
Having just spent a large part of the weekend tracing and adjusting some zellij I tend to agree.
Annoyingly, though the example I was reproducing (from an image of a tiling on a wall) had either been squashed in one dimension or the original was asymmetric in an unexpected way. Like an octagon that was 120 mm in one direction and 130 mm in the other.
I envy you for doing that. Actually one of my bigger dreams is to build a house full of zellij tiles. Until then a smaller dream is to spend couple of days at Dar Seffarine hotel in Morocco [1].
I checked out Zellij a while ago, because it looked all shiny, but then realized that tmux (that I've been using for years) does everything that zellij does, except it is more widespread (runs on remote systems which are not the most recent versions) and better debugged. So I went back to using tmux. But at least I got motivated to learn more about tmux :-)
Not accounting for tastes and preferences, but it is decidedly not true that tmux does everything Zellij does (just some very minor examples are: true floating panes, true multiplayer support, stacked panes, etc.)
As for prevalence: this very often has to do with the distributions themselves and their ability to accept certain (rust) dependencies.
Otherwise though, I always say Zellij is not competing with tmux. That tool choices should be more equivalent to clothing choices than to choosing a school for your kids. Choose what you like, there should not be religious disagreements here.
I trust the Debian maintainers and couple of teams and individuals (including Aram), but there is no way I can remotely build trust for the number of people needed to build a convenient tmux/nvim development environment. I really, really wish neovim would have a sandboxed plugin environment like this.
[Goes without saying that the sandbox is not a replacement for trust and vice versa, but it would be a big step forward. What we are doing right now with plugins in this space is terribly dangerous.]
This looks very interesting! It's great to see innovation in the terminal multiplexer space. tmux has held the crown for too long, and it's worth revisiting this space with modern approaches.
I really like the concept of quickly hiding and showing a pane, and spawning it for a single command that can be easily repeated with Enter. Quick scrollback editing is great as well. I often do this manually in tmux with copy/paste, or re-running the command with `tee`, which is a bit cumbersome.
One nitpick would be to have an option to minimize or remove the borders around panes. It's nice to have extra metadata around a pane, such as the CWD, but space is precious in terminals, and showing borders around every pane feels wasteful. Maybe this is already possible, I haven't looked at the docs yet. Will definitely give this a try soon.
EDIT: Ah, kudos for the nice roadmap[1]! It seems this might already be planned as part of [2].
So, I understand the value of tmux for detaching and restoring sessions. What I don't really understand is why I'd want to use something like this instead of tiling and managing sessions / windows / panes within my terminal emulator. Kitty has tremendous support for all kinds of features, including capturing and processing the output from commands, piping scrollback buffers to external commands, scrolling to previous command prompts, searching and highlighting output dynamically, and much more besides. The overlap is significant between tools like this and tools like kitty or iTerm. Am I missing some advantage in putting this functionality on the server rather than the client?
Taking it even one step further, I probably would really be better off managing the window tiling in my window manager, however, I still have yet to settle on a tiling window manager that works well enough under wayland and supports everything I need well enough to give up the Gnome shell. I did try https://github.com/YaLTeR/niri this past weekend and it's pretty great. niri is inspired by PaperWM. I used PaperWM for a while and it was pretty awesome but suffers from the same issue as all of the tiling extensions for Gnome shell: they are never stable enough for for my daily use because Gnome is a moving target and the gnome shell extension API isn't really up to the task of radically transforming the window management paradigm. Projects like PaperWM have too many downsides that are really difficult to overcome, despite their significant innovation and appealing UX.
One big use case is the ability to attach/re-attach to sessions running on some remote host. When connection is lost, you don't lose the session and can easily re-attach to it
Could anyone offer recommendations on "riced" zellij configuations, or just a demo where it shows doing with (say charts of disk usage per folder), watching a movie with mpv + keeping a vim to type on?
I like how easy zellij was to set up and it's capabilities to define new layouts as well as the default way of displaying contextual shortcuts that one can disable after one memorized the most important shortcuts.
What I would still like to see is support for kitty image protocol [1] so I could use e.g. image.nvim [2] which currently works in tmux (which I migrated away from in favor of zellij).
Never in my life understood the people who invented terminal multiplexer to launch several copies of vim in different terminals. As much as you want, you can create tabs, terminals, floating windows, split panes and even recursively nested vims within a single instance of vim itself, like this: https://imgur.com/a/vUd9OOU
Can someone explain why this is needed and how it's better that of vim's splits tabs and panes?
If you e.g. use LSPs or similar tools it usually is better to separate different projects into different Vims. Most of these tools rely on some kind of project root and may get confused if you have different ones opened in the same Vim instance.
I personally also like the separation and navigating my Tmux is very fast. To me Vim is the perfect editor but I don't want to use it as windowing or operating system replacement. Obviously I use tabs and windows in Vim but always only regarding the project I am working in. E.g. I use tabs for diffs a lot and reviewing.
The solution is easy though, you can use :tcd to set the root dir per tab for the project tooling in this tab and I never had any issues with separate projects this way.
I guess the way we operate terminal tabs and splits is just something we get used to once and never change, even if it tooling to do it starts to layer on top of each other :)
Yea you have a workflow and usually stick to it if it's good enough. For me I have many projects in different tmux windows and I name them to keep an overview.
I am convinced that having all of this in vim would make it harder for me to find things :)
But you are right.. I use splits inside Vim and with Tmux and sometimes I get confused when switching.
In my opinion tmux has two shortcomings. The built in session manager is very limited(so I am using my own script instead). And the ability to save and restore sessions is achieved using two plugins that can take some time to wrap your head around and make them work.
Zellij on the other started with the goal to be as user friendly as possible and basic tmux features(such as detach) were implemented very recently. There are too many elements on the screen, and each actions requires you to go into a "mode" which feels like unnecessary overhead after getting used to the way the modifier/prefix approach works in tmux. And I am more then fine with modes(I use neovim and emacs with evil keybindings) but when it comes to terminal multiplexer or window manger I feel a modifier provides less friction.
When its all said and done and tmux is configured I feel I am getting
a more fluent experience. Unlike vim and emacs I don't see a lot of distinction between tmux and Zellij and I don't see a many reasons to switch at the
moment.
Session detach was added 2+ years ago and tmux keybindings work out of the box. You can also remove any part of the UI you do not like and there are some pretty friendly built-in alternatives that take up less room.
That being said - use whichever software makes you happy. I'm just a stickler for facts. :)
Good to know that Session detach was added 2+ years ago.
Are tmux keybindings first class citizen in Zellij? and what would you say sets Zellij apart from tmux based on your experience?
Yes they are. They work out of the box as I mentioned. This is what originally helped me move from screen to tmux, so it was important to me to provide the same experience.
As for comparisons to tmux: I shy away from those. Just like I shy away from comparing chocolate cake to lemon cake. Both are awesome. Use what you like and decide for yourself.
I want to love Zellij, but it eats up way too many keybindings. Yes, I know about mode lock, but then it's an extra two or four keypresses for everything I want to do.
I'd love Zellij with true tmux style keybindings - a single prefix key followed by a non-modified letter.
With zellij, you have to unlock, do your zellij command, then lock again.
Last time I tried it, it didn't add features I really felt would change my workflow, and the memory consumption was rather high.
In general I notice a lot more resources used for terminal multiplexing, starting with GPU-focused terminal emulators (or even ones using Electron).
Maybe I missed something, I probably could run screen + xterm and barely notice any difference. Almost getting a bit of FOMO here, but have yet to see e.g. a screencast that would make me envious.
It's always interesting to me to see CLI users who are so invested in their development environment that they end up recreating the GUI IDEs they so disdain. Like vim users who insist that Jetbrains or VS Code is unnecessary after they configure vim with syntax highlighting, code completion, and gdb support with breakpoints
I use terminal … a lot. Alas! These days it’s the terminal bundled with my IDE (intellij). I have multiple projects open and never really found a good workflow around terminals and IDE because I absolutely must use both.
This looks cool, but it looks like it’s geared towards vim users as it overrides some Emacs/readline keybindings. If I ever switch to vim, I will give it a try.
We actually looked into it and found it to be the Rust allocator after all (the memory is freed after a day or two and afaict should not cause oom issues). I'm sorry for not writing this up in the issue, this was heavily investigated by another maintainer and they have not yet found the time to write this up.
Frankly i've spent too much time in the past fiddling with complex confs and tools which expect the user to spent days figuring out a conf which work for them. Then if you don't use the tool for 1 month, or simply don't edit the conf for a big while you've forgotten half of it.
Zellij has a conf file, it took me a bit of time to tweak it at first, but i know I can understand it in a pinch. Same thing for actually using it, it's mostly discoverable.
And most importantly, it is very clear that simplicity and predictability are big priorities. It shows everywhere in the project, I totally vouch this approach and tend to do the same thing on my work projects. I know from experience than understanding your user's needs and getting out of your way to make their life easy by not having to think about how the implementation is done is really much harder that just making a tool configurable and extensible...
So, big kudos to you Zellij devs !