Because it's not immediately obvious, Zellij is a terminal multiplexer like tmux or GNU screen, whose distinguishing feature is that it comes with more built-in functionality, has a more discoverable UI, and a more opinionated/modern default configuration while still being highly customizable (as demonstrated in the OP).
HOT DAMN! Over the last few weeks I've wished almost daily I was proficient in tmux, but it's annoying to get started in because you have to look up EVERYTHING. I just tried Zellij (they have a "try without installing" command on their website) and it's exactly what I wanted Termux to be. Thank you so much for this comment!
Too bad it isn't a drop in replacement for tmux because of memory usage. There are memory leaks and even without that the base memory uses is a couple hundred megabytes. Tmux on the other hand, consumes only tens of megabytes of memory.
Hey, there are no memory leaks that I'm aware of (there were a few, but we plugged them in recent months). If you know differently, I'd appreciate an issue report.
If you run e.g. btop or bpytop in a separate zellij tab, zellij will eventually gobble up all your memory and die.
In the beginning I wa very entusiastic and switched from tmux to zellij on remote machines, but as I usually have btop running in a tab it would die in a day or two, so now I'm back to using tmux on remote machines and reserve zellij for local (and make sure I don't run btop in a tab).
I'm now running v0.37.2 on a remote machine with 3 tabs: a shell, syslog spooled by lnav, and btop. To me it looks like it grows by 2 kB RAM every minute. I am logging to a file with timestamps, and we will see the results tomorrow.
In the course of less than 12 hours zellij grew from 93 MB to 1227 MB in roughly 2 kB increments per minute. Closing the tab running btop will release the stolen memory.
I will append a comment to the Microsoft GitHub issue mentioned above a little later.
Thanks! If you could also specify how you measured it and attach some debug logs (there are instructions in the issue template) that would be great. Because my instance has run overnight without issue and I'd love to be able to reproduce this.
But I still use it all the time now — I found it so much easier to get up to speed with relative to tmux. And it's getting better all the time, so I'm happy to invest in it...
Its not tmux, are you sure you're engaging its binding which enables/disables its binding map, I belive Ctrl+G IIRC, unlike tmux which prefixes its bindings with a customizable chord
Hijacking this for a question I've been wondering about. For context, I'm a long-time tmux user who spends 90% of my time in remote shells.
Ideally, I'd have my WM handle panes, layouts, etc. "Terminal multiplexing" seems to me to be misplacing client/UI concerns. Session persistence is the concern of the server, and multiplexing should be handled by ssh. However, getting the client terminals to coordinate nicely (e.g. reattaching to the appropriate sessions, opening new terminals in the same remote working directory) require more sophisticated clients than exist currently (to my knowledge).
Does anyone feel similarly? Anyone have a setup that approximates what I'm looking for?
I'm using resurrect tmux plugin configured to rerun ssh commands, it's not perfect as it's not restoring remote session, but at least you have session open to right host in pane that you expect with scroll history.
I was checking it like a year ago and it was cool but lacked some functionalities that i relied on daily basis (in comparison with tmux). I'm sure that some of those could be already implemented but plugins could probably fulfill rest of those.
For sure i see need for some kind of plugin "package manager" here.
on one hand this would help with discoverability of plugins, but more importantly with updates. checking each of plugin every so often isn't convinient and in such systems i usually check once or twice a year if there is any update.
It seems odd to distinguish between a plugin and a program running in a terminal pane. This seems to imply you must reimplement all such functionality as a new plugin, instead of just running your preferred tool, as usual, in a terminal window.
For example, they have implemented a file explorer as a plugin. But this means you can only use it when Zellij is available, and not as a standard tool on another system. This reduces flexibility and means you need different tools in different contexts.
I'd love to be corrected, but I can't think of any good reason why a special file explorer needs to exist, just to be coded to this plugin standard, instead of as a normal terminal program.
1. Ease of distribution - distributing a precompiled wasm blob is immensely easier than distributing an application
2. Sandboxing - both on the fs level and regarding special permissions, which brings us to
3. Stronger capabilities - you can use the terminal workspace around you by manipulating panes, tabs and other plugins, creating a workspace experience rather than a single app
4. More knowledge about the application - want to trigger when the user enters a certain folder? When a certain pane is focused? When certain text appears on screen?
5. Composability - integrate with other plugins to render a dashboard-like experience rather than a single app that a user needs to manually compose
While some of these are also achievable with native apps, I have found that if you give users (developers in this case) opinionated defaults that make integration easier - you'll get more people building more interesting things. Even if they technically can implement them all on their own.
Maybe you're focusing too closely on the specific example. It's interesting to me in the large for sure.
For one, since plugin permissions seem to be on the roadmap, users can expect to be able to write and run third-party code with a bit more confidence than if it were just another unix process.
Looking further down the line, imagine a pluggable web/native frontend for Zellij. At its most basic level of operation, it would still serve as a full terminal multiplexer, but it would also have the potential to do anything the containing runtime supports (render images, play video, render rich inputs/controls).
I wasn't imagining this before, but I kind of am now...
It looks pretty cool. Is there a plugin that is just "convert this program into a plugin"? i.e. say I'm doing some networking set up and I want to check whether what I'm doing is improving or reducing effective performance. I would like:
1. One pane with my UDP benchmark between two of my machines
2. One pane with my UDP benchmark between two other machines
3. One pane which is a normal terminal where I'm going to make my changes
So what I'd do is make my changes in normal terminal, then switch over to #1 and hit Enter and it runs, then switch over to #2 and it runs. I don't want to write a specific plugin for my UDP benchmark tool. I want a plugin that takes a pre-baked command (with flags and arguments) and turns it into a pane that I can just switch to and hit Enter.
Honestly, I currently use a tiling terminal emulator (iTerm2) and it's not bad, but I have to hit Up+Enter and then that's overlapping with the history of whatever shell is on that machine.
You can either open them through the cli with "zellij run -- <your command>" when inside a zellij session, or set them up in a layout so it opens all of the ones you want in a new tab arranged the way you like.
More interested in when they'll implement concurrent, switchable sessions, one of the main reasons one would continue to use tmux, but this is nice development
What do you mean by concurrent, switchable sessions? Googling those terms didn't show me anything that (in my limited knowledge) tmux has that Zellij doesn't
And for those who are tmux users, zellij can be configured to be more space efficient, ie reduce borders to a single line. There are even tmux bindings.
I've since grown fond of zellij's locked mode which hides all keybindings behind a Ctrl+G toggle. That behaves more like vim modes than the awkward Ctrl+B in tmux.
Very cool! As a wasm fan, I'm excited to see this and really appreciate the detailed write-up. As a maintainer of Extism[0] (a wasm plugin system framework) I'm curious if our project came up in your research for this, and if so, what is missing or kept you from considering it as a solution?
I'm pretty sure our plugin system predates your project (it's been around since before our beta was released in 2021, we've just given it the attention it deserved right now).
I'd definitely have wanted to outsource this though if we didn't have the infrastructure in place already. Extism seems solid.
First: wasm is the perfect plug-in language, as it provides a high level of isolation and therefore security for the host app.
Second: the promise of wasm is that you can write it in any language. I think this is compelling for any application that seeks for extensibility.
Wether all this is worth the effort is probably the actual question. Maybe we will be surprised by killer plugins that wouldn’t be possible with regular plug-in systems…
> Maybe we will be surprised by killer plugins that wouldn’t be possible with regular plug-in systems…
It's less "this wouldn't be possible" and more the fact that the existence of plugins that are sandboxed and access-permissioned makes me far more likely to seek out and install plugins in the first place, since it lowers the trust barrier. It's the same reason why I browse random websites freely while also being loathe to install random binaries on my computer. Being language-agnostic is just icing on the cake.
You might be missing the fact that WASM nowadays doesn't necessarily have anything to do with web browsers. It was initially designed for running in web browsers, but in the last few years there's been a lot of activity surrounding embedding WASM runtimes in processes other than web browsers. Mostly the idea is for it to be a way to execute untrusted / customer code (e.g. "plugins") with sophisticated sandboxing, etc.
Wasm has the promise to be a single target for your plugins that could be written in node/rust/python and the consumer won't have to have that specific version of python installed. That and the possibility to sandbox a plugin so my repl function can't also upload my ssh keys would be nice.
WASM doesn't mean this has to be true, but it could be.
It's both dynamically loadable & doesn't require any external dependencies. Each WASM container has its own heap, so you don't need e.g. glibc versions to be the same, which is otherwise a PITA for plugins.
what's coming next is replacing wasmer with wasmtime [1], the runtime closely following wasm and implemented by the same people designing the standard itself.
While that's not true, since the Wasm spec is designed mainly by the browsers, I appreciate the hustle-trolling haha
In any case I wonder what's the need for try to push Wasmer down. Here are your previous comments, all hateful against Wasmer on different announcements:
https://github.com/zellij-org/zellij