I get it from the other comments that it's a terminal multiplexer, and considered an alternative to tmux. But tmux and screen are well established, and should take the opportunity to explain in what way it is different from those.
* Ssh in to myserver.cloud from my laptop. Run Zellij. Fire off various long-running processes in multiple tabs.
* On my commute home, ssh in from my phone, run `zellij attach`, and check on the status of those processes.
* Once home, ssh in from my desktop, run `zellij attach`, and continue where I left off earlier.
Tmux is nice, but Zellij fits my brain a lot better. Plus, it has a lot of UI affordances to discover features without me having to memorize keystrokes. I use these kinds of tools often enough to care about them, but not so often or in such depth that I'm any kind of a power user. There are certain things I do so rarely in Tmux that I have to look up the manual every single time I do them. With Zellij, I don't have to.
All text editors worth using have a way to open a terminal for that one time you need it, everything else should be a GUI (with all the advantages that come with it).
I'm a terminal guy because most UI I use is just unintuitive and requires a lot of mouse clicking - using mouse is just inconvenient to me. And often there are no tools for what I want to do, or rather, I'd need to open many tools to do something simple like change a file on a remote machine.
But I like a nice IDE, I use DB explorers, I use cloud code to write GUI for data processing and reporting visuals. Terminal is just a "killer app" that's useful for almost everything. So, if you're using regardless, why not make the experience better?
A decent terminal emulator like kitty solves all of this.
Until a few months ago I used to use tmux + foot (tiny terminal), and I enjoyed the setup because I could copy over my tmux config to remote hosts and work as if nothing changed. As I'm mainly working local now, I'm now mostly using Kitty.
> All text editors worth using have a way to open a terminal for that one time you need it.
Is this not somewhat self-contradictory? Having the terminal in the editor or having the editor in the terminal are both about having one tool that rules the others. The only difference is which one you choose to be the ruler.
VS Code still has the same style from 2018.
TUIs and CLIs are often keyboard centric only use as many resources as it takes to do the task, and then minimal resources to draw the text. Most CLIs also follow the Unix philosophy of doing one thing well, so you can get an output from a CLI and then pipe it into another.
At work I literally use the same workflow at home across two different operating systems because they both share a terminal. I don't even know how to switch workspace on a Mac because I don't need to, tmux sessions fulfil the same task.
basi cli tools yes, but software like the one we're commenting on has a TUI so complex they simply emulate graphical user environments and widgets but on a text rendering stack, akin to web apps pretending to be graphical applications on top of a markup language, except they do it out of necessity because that's how the web works.
If you want to draw graphical user interfaces on an operating system just use the... actual graphics stack. There's terminal apps with widget frameworks now that painstakingly try to reproduce what every OS ships with just because it's.. cool to be a terminal hacker or something?
So obviously it's terminal-centric.
There is a higher learning curve, and we can argue about the tradeoffs you make, but some powerful tools can be difficult to learn to use. Complexity != bad design; sometimes you're just exposing an underlying problem space that can't be simplified without being cut off from part of the solution space.
Everything can be controlled through the keyboard, typing into every window does fuzzy search of its contents (and that window might contain a list of code symbols, a list of database tables, a list of search results, or many other things).
Every action can be bound to a key combo of your choice. Every interaction with the GUI can be stored as a macro, edited and replayed.
And so on, and so forth.
I'll also add that (like the parent comment) I did not get the appeal. Not until I forced myself to use it more and saw the benefits.
By the way, using a GUI doesn't automatically using the mouse for everything, think of GVim or Emacs. the problem with terminal emulators is the emulating part, where they are forced to comply with the idiotic rules from the '70s.
Look into tailscale's installation script, they wrapped everything into a function which is called in the last line — you either download and execute every line, or it does nothing.
It usually happens on large files though, due to simple statistics, but given enough users, not hard to imagine it happening with a small script...
It has a browser built in, which is "just" an iframe, and it definitely doesn't function as a full blown web browser, but it does work for previewing your dev work, and given it's a dev tool it makes sense that the experience would be editor+debugger+tools first, with browser as a second class citizen (rather than chrome with an embedded terminal which would be the other way around).
I'm working on a `tweety edit` command which open arbitrary files in your $EDITOR of choice in a new tab.
I've attempted to move over a few times, and while this is certainly user skill, it just felt too different from screen/tmux. Perhaps I should bite the bullet and force myself to get used to a new paradigm...
Can anyone help me learn why this over, say, kitty?
I believe it's positioned to be more user-friendly than tmux but I've already got things memorised with tmux and it wasn't bringing anything new to the table, so I didn't try zellij for more than a few days.
The modal nature of Zellij is nice though.
like this:
tmux send-keys -t 0:1.1 "ls" Enter
edit: well, yes, you can:
zellij action write-chars ls
zellij action write 10