They just merged sixel support (the oldest images in terminals protocol).
Which shows that they are going places gnu screen and tmux have never wanted to.
In zellij you can scroll through and flip between different terminals that show sixel images, it's quite neat, knowing that such leaps are being made.
Meanwhile as a longtime GNU Screen user, I've been using workarounds to pass through hyperlink markup (ls --hyperlink) and thinking about what I could do if there was sixel or other image protocol support - Zellij already supports hyperlinks just fine, and now images so it is very promising.
You've got my attention with the sixel support. I use screen quite heavily, but I'm open to switching for something like that.
I think I use screen in an unusual way, I know a few keyboard shortcuts but 99% of the time I use the command line.
If you press Ctrl-A :, you get a command line with tab completion to access all the screen commands. I have no idea what the shortcut is to split a window, because I just use :split. Same with :resize, :focus, :remove, :paste, :title, etc, etc. I'm quite happy with one less application I need to memorize bindings for, and I'm reluctant to give that up!
I've been using Zellij on both Linux & Mac for around six months.
It's great! For someone who wants a terminal multiplexer but a) doesn't feel like learning all the idiosyncracies of tmux and b) is OK with adding some configs in toml — it's ideal.
The downsides are that it's not perfectly stable — maybe once a month I get a panic — and some terminal cobwebs aren't encapsulated — e.g. it's not possible to use "[" in key mappings.
let's skip the part on idio-something of `tmux`, but the very much selling point of screen and tmux, among multiplexing, as support of detached state and being able to reattach later on.
Zellij seems to be targeted on local machine of end user (desktop, laptop) vs being used on server through ssh. Nothing bad about that of course, just this product is not for me.
User friendly shortcuts ? It uses Ctrl/Shift + functions keys all around... Not user friendly for me, on my laptop I would have either to hit Ctrl/Shift + Fn + plus one of the top row keys, or go into the BIOS, reverse the the top row so that I can press directly a function key but give up on the possibility of hitting volume/brightness up/down... I am sure it works for some though.
Please do not pipe scripts downloaded through curl into bash. Use a package manager. That way the downloaded binary can be verified against a checksum and/or GPG signing.
Please lend your own time and energy to generate packages for bespoke distributions and package managers. You will need: deb, rpm, apk, AppImage, casks, tars, and likely more. Make sure to spend your time submitting your package to maintainers for each repository/registry for each distribution and each distro version. Don't forget to test each and every permutation!
Is all that too hard? No problem. Stand up your own repository for each distribution mechanism and instruct the user to run a bunch of random curl and key handling commands to bind their machine to this new software supply chain attack channel. At least this 'potentially malicious' code is being checksumed/gpg verified!
-- the point --
'curl | sh' is inherently no different from a trust perspective then issuing a package installation command or installing a new repository source for a package manager. Each user makes the value judgement if they trust the software or not. Your free to run the 'curl' part and inspect the script, or contribute packages to the byzantine linux/unix ecosystem if it boils your blood so hard.
Please don't contribute worthless and irrelevant comments like this. As you doubtless well know, piping from curl into bash is something that a large subset of respected programmers think is reasonable, and another rather tedious subset do not. For example, the entire Rust community clearly has a consensus that it's reasonable: https://rustup.rs/ As does homebrew https://brew.sh/ and pyenv https://github.com/pyenv/pyenv-installer#install to name whatever came to my mind in 30s thought.
Since the debate has such large numbers on both sides, your individual opinion on it is neither interesting nor germane.
I love Zellij - have been using it for the last eight months. However, I wish it had a real programming language for configuration (since a program like this can be so versatile) instead of TOML.
Not to be dismissive, but I have no idea why I should want to install this. I actually just spent a few hours setting up a tmux configuration yesterday, so I feel like I'm in the target audience for this, but...
I can configure panels with YAML, it looks like. Why would I want to change my resizable panes for a set of static ones? It supports arbitrary plugins, is says. But can't I just run any program in tux, so what is the point? The screenshots seem to mostly show how loud and colorful the chrome is, which seems distracting. And then the roadmap seems to be the only feature list, does that mean the software is actually "batteries-will-eventually-be-included"?
Hey, Zellij dev here. I'll try to answer your questions:
- regarding layouts/panes: the panes you configure in the layouts are still resizable a runtime. It just saves you the initial setup. In Zellij you also have a generic non-directional "do what I want" resize, btw.
- regarding plugins: the plugin system is indeed very much a work in progress, mostly because we're an OSS volunteer project and the person in charge of it had to AFK for a while. That being said, I think it's not very difficult to imagine how plugins will be different from normal apps? Think about interaction with panes/layouts, easy distribution, interaction with the terminal assets themselves (imagine custom expandable folds depending on content, notifications depending on content, etc.) and more along those lines.
Multiplexers are useful when logging to a remote server. You can open a bunch of things without separate ssh session for each and you avoid issues with breaking connections cancelling your long time jobs (got me a couple of times when migrating data).
I also use iTerm2 on macOS, with tmux. Here are the main reasons why I do that:
- I can create window splits running multiple shell sessions in each pane, and then "zoom" in to an individual pane to focus on what I'm doing in that shell session.
- I can organize my work into named sessions, with multiple windows within each session, and panes within each window, and navigate between these using the keyboard.
- I can persist that session/window/pane structure across machine reboots (tmux-resurrect). The result is that I always have the same set of tmux shell sessions running, corresponding to the different projects that I work on.
- The same keybindings for session/window/pane management work whether I'm on MacOS or on a remote linux machine running tmux.
But I'm not a very advanced tmux user and there's a lot more I could do. If you look through the tmux feature set it will give you an idea of what you can do beyond what you can do with iTerm2. iTerm2 does have its own "tmux integration mode" but that's never quite appealed to me: I use tmux specifically because I want the tmux style of window splits etc, and because I want the familiar keybindings to be the same when I'm on a linux machine. So placing tmux behind the iTerm2 UI isn't what I'm personally looking for. I think! Or maybe I've misunderstood the iTerm2 feature.
The interface is very discoverable, unlike screen or tmux. You can start using it productively even before reading any documentation. The keybindings feel like a cross between vim (modal) bindings and CUA bindings.
I assume Neovim users don't need to care about this thanks to in-built terminal and ability to split, resize and switch between them using standard vim key bindings.
I'm the original Zellij creator. I am and have long been a vim user.
I created this tool originally for people like us. It has lots and lots of extra features and functionality (eg. opening the current pane scrollback inside your default editor in-place).
But for the Neovim users (including myself), this is handy if they would like to use other applications besides neovim while keeping their neovim session open.
I say this as a vim user, but it reminds me of what nano is compared to vim. With zellij, you can jump in blind and learn how it works. Compared to tmux, which is great, but like vim, requires more upfront learning.
And the configuration is awesome. I’ve defined workspaces that look like a sophisticated IDE with little effort. It always seemed to be more effort doing the same in tmux.
Serious Q: Has a serious emacs user checked this out? It looks exciting, but I’m a full time, long time, emacs -nw multi-buffer M-xshell user. Am I going to be disappointed bcs either it’s not going to let me run emacs on its sub windows, or it will have unresolveable key binding incompatibilities?
Hey, Zellij dev here. You should have no issue running emacs inside a Zellij pane. There might be some keybindings collisions, but you can always configure your way out of it if you like.
In general the problem of colliding keybindings is a hard one, and one we plan to address in the near future as we chip away at some technical debt that stands in our way.
As a serious emacs user, this looks like a stripped down version of emacs. There's no reason to use this if you're already using emacs. Its UI even looks like emacs, with the modeline and minibuffer.
[+] [-] kzrdude|3 years ago|reply
Which shows that they are going places gnu screen and tmux have never wanted to.
In zellij you can scroll through and flip between different terminals that show sixel images, it's quite neat, knowing that such leaps are being made.
Meanwhile as a longtime GNU Screen user, I've been using workarounds to pass through hyperlink markup (ls --hyperlink) and thinking about what I could do if there was sixel or other image protocol support - Zellij already supports hyperlinks just fine, and now images so it is very promising.
[+] [-] taviso|3 years ago|reply
I think I use screen in an unusual way, I know a few keyboard shortcuts but 99% of the time I use the command line.
If you press Ctrl-A :, you get a command line with tab completion to access all the screen commands. I have no idea what the shortcut is to split a window, because I just use :split. Same with :resize, :focus, :remove, :paste, :title, etc, etc. I'm quite happy with one less application I need to memorize bindings for, and I'm reluctant to give that up!
Does Zellij do something similar?
[+] [-] mark_l_watson|3 years ago|reply
[+] [-] maximilianroos|3 years ago|reply
It's great! For someone who wants a terminal multiplexer but a) doesn't feel like learning all the idiosyncracies of tmux and b) is OK with adding some configs in toml — it's ideal.
The downsides are that it's not perfectly stable — maybe once a month I get a panic — and some terminal cobwebs aren't encapsulated — e.g. it's not possible to use "[" in key mappings.
[+] [-] CoolCold|3 years ago|reply
Zellij seems to be targeted on local machine of end user (desktop, laptop) vs being used on server through ssh. Nothing bad about that of course, just this product is not for me.
[+] [-] foolinaround|3 years ago|reply
https://zellij.dev/roadmap/
[+] [-] donio|3 years ago|reply
[+] [-] Kaze404|3 years ago|reply
[+] [-] telagraphic|3 years ago|reply
[+] [-] rgoulter|3 years ago|reply
I love that it's more discoverable, with the keybindings displayed more readily.
I think one feature I use from Tmux frequently enough is switching between sessions. It's not currently something the zellij client can do.
[+] [-] pathompong|3 years ago|reply
https://www.byobu.org
[+] [-] cassepipe|3 years ago|reply
[+] [-] tpoacher|3 years ago|reply
[+] [-] slang800|3 years ago|reply
[+] [-] ReganLaitila|3 years ago|reply
Is all that too hard? No problem. Stand up your own repository for each distribution mechanism and instruct the user to run a bunch of random curl and key handling commands to bind their machine to this new software supply chain attack channel. At least this 'potentially malicious' code is being checksumed/gpg verified!
-- the point --
'curl | sh' is inherently no different from a trust perspective then issuing a package installation command or installing a new repository source for a package manager. Each user makes the value judgement if they trust the software or not. Your free to run the 'curl' part and inspect the script, or contribute packages to the byzantine linux/unix ecosystem if it boils your blood so hard.
Practicality is a feature sometimes.
[+] [-] samatman|3 years ago|reply
That would be using your tools, not kvetching online. And we can't have that.
[+] [-] da39a3ee|3 years ago|reply
Since the debate has such large numbers on both sides, your individual opinion on it is neither interesting nor germane.
[+] [-] yunohn|3 years ago|reply
[+] [-] yewenjie|3 years ago|reply
I also miss a few tmux plugins.
[+] [-] kzrdude|3 years ago|reply
[+] [-] CGamesPlay|3 years ago|reply
I can configure panels with YAML, it looks like. Why would I want to change my resizable panes for a set of static ones? It supports arbitrary plugins, is says. But can't I just run any program in tux, so what is the point? The screenshots seem to mostly show how loud and colorful the chrome is, which seems distracting. And then the roadmap seems to be the only feature list, does that mean the software is actually "batteries-will-eventually-be-included"?
[+] [-] imsnif|3 years ago|reply
[+] [-] forrestthewoods|3 years ago|reply
[+] [-] bsnnkv|3 years ago|reply
[+] [-] bentcorner|3 years ago|reply
[+] [-] avinassh|3 years ago|reply
[+] [-] d3ckard|3 years ago|reply
[+] [-] Myrmornis|3 years ago|reply
- I can create window splits running multiple shell sessions in each pane, and then "zoom" in to an individual pane to focus on what I'm doing in that shell session.
- I can organize my work into named sessions, with multiple windows within each session, and panes within each window, and navigate between these using the keyboard.
- I can persist that session/window/pane structure across machine reboots (tmux-resurrect). The result is that I always have the same set of tmux shell sessions running, corresponding to the different projects that I work on.
- The same keybindings for session/window/pane management work whether I'm on MacOS or on a remote linux machine running tmux.
But I'm not a very advanced tmux user and there's a lot more I could do. If you look through the tmux feature set it will give you an idea of what you can do beyond what you can do with iTerm2. iTerm2 does have its own "tmux integration mode" but that's never quite appealed to me: I use tmux specifically because I want the tmux style of window splits etc, and because I want the familiar keybindings to be the same when I'm on a linux machine. So placing tmux behind the iTerm2 UI isn't what I'm personally looking for. I think! Or maybe I've misunderstood the iTerm2 feature.
[+] [-] himujjal|3 years ago|reply
On windows it was Windows terminal.
On Linux, I was using Konsole (KDE).
Just more than enough
[+] [-] RockRobotRock|3 years ago|reply
[+] [-] sreevisakh|3 years ago|reply
[+] [-] uwagar|3 years ago|reply
[+] [-] lenkite|3 years ago|reply
[+] [-] imsnif|3 years ago|reply
I created this tool originally for people like us. It has lots and lots of extra features and functionality (eg. opening the current pane scrollback inside your default editor in-place).
Check it out if you like.
[+] [-] jcpst|3 years ago|reply
But for the Neovim users (including myself), this is handy if they would like to use other applications besides neovim while keeping their neovim session open.
[+] [-] w0m|3 years ago|reply
The ability to close terminal and reconnect to it later is a key defining reason I run ~90% of my neovim sessions inside of tmux.
[+] [-] jcpst|3 years ago|reply
I say this as a vim user, but it reminds me of what nano is compared to vim. With zellij, you can jump in blind and learn how it works. Compared to tmux, which is great, but like vim, requires more upfront learning.
And the configuration is awesome. I’ve defined workspaces that look like a sophisticated IDE with little effort. It always seemed to be more effort doing the same in tmux.
[+] [-] stavros|3 years ago|reply
https://zellij.dev/documentation/img/layout-template-example...
[+] [-] abrax3141|3 years ago|reply
[+] [-] imsnif|3 years ago|reply
In general the problem of colliding keybindings is a hard one, and one we plan to address in the near future as we chip away at some technical debt that stands in our way.
[+] [-] cmrdporcupine|3 years ago|reply
Too much overlap in functionality. And windows in windows in windows in ...and another set of keybindings to memorize.
To get a persistent session, just run Emacs in screen.
[+] [-] teddyh|3 years ago|reply
(Yes, Emacs can still run in terminals if you want to. You just don’t need to keep pretending it’s 1979.)
[+] [-] Ferret7446|3 years ago|reply
[+] [-] lucidphreak|3 years ago|reply
[+] [-] obiwanpallav1|3 years ago|reply
Screenshots in the README!
1. https://github.com/pallavJha/chaakoo
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] memorable|3 years ago|reply