imsnif

Yes! With built in authentication.

For 1 - there's actually a nice proposal from WezTerm to make this an all-purpose general protocol that I hope happens: https://github.com/wezterm/wezterm/discussions/4889

For 2 - I think this can be achieved with scroll vertical/horizontal scroll regions (which should also boost performance a bit). I hope to implement this in the future.

Hi all, I'm the author of this article. Happy to answer any questions.

Hi, I'm the author of this article. Happy to answer any questions.

When I tried to get into programming as a teenager, I opened a graphical IDE and was immediately overwhelmed by a barrage of menus, popping windows and tooltips. This led me to believe programming is not for me. In later attempts I used vim (back then that's what people used to recommend those starting out with perl) and felt right at home.

These days I still use vim (almost stock) for everything (right now mostly Rust). This is totally anecdotal, but I'm usually more productive than my teammates - mostly because of the initial hurdles of getting into a new codebase or parts thereof. I don't have anything to set up, I just open it up and grep my way to success.

Every now and then I try to open an IDE and force myself to work with it a little bit just to be sure I'm not missing anything. The visual overload and lack of advanced editing are just too much for me. Going back to vim is always a breath of fresh air.

I'd sooner use nano/notepad.exe than any sort of graphical IDE (though I prefer vim).

I'm not saying this is the best way, I definitely do not recommend it to those asking me how to get into programming, but it's definitely the best one for me.

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)

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.

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.

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. :)

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.

You can make it as compact as you like: https://zellij.dev/documentation/faq#the-ui-takes-up-too-muc...

Hey, you can remove borders around a pane at runtime with (default) `Ctrl p` + `z` or from the config with `pane_frames false`.

The session name yes, the branding no. You can create a custom plugin though instead of the built-in UI ones and render whatever you like...

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.

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.

Keeping track is hard sometimes, I saw it again in the issue as you mentioned. :)

I'm like 90% sure this was fixed - if you'd be willing to try with a recent Zellij version, that would be great.

Otherwise, I'll try your reproduction myself and will fix if I can reproduce. Thanks.

Sure thing! Btw, plugins can also open these command panes, this is how the multitask "mini-ci" plugin works.

Hi, Zellij has this feature. Please check out command panes: https://zellij.dev/documentation/zellij-run.html

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.

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.

Very soon! We want to implement it as a default plugin and wanted to release this system first.

Good question!

A few reasons:

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.

Yes: https://zellij.dev/tutorials/basic-functionality/

Zellij can attach/detach sessions just like tmux.

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).

Check it out if you like.

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.

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.

Fair point, but this post was mostly to tell how things are today. And these days most (all?) terminals the reader will interact with would be ANSI.

True, and thanks for pointing this out. But this example is there to illustrate the basic relationship of shell<->terminal-emulator without going in to too much details that might confuse those readers for whom it is intended.