Live data from Hacker News

Zellij – A Terminal Workspace and Multiplexer

zellij.dev

191–200 of 248 posts

Re: Zellij – A Terminal Workspace and Multiplexer

#192
post #150

I see a lot of projects on here where the tagline is that they're written in Rust. Shouldn't that be completely opaque to the user? I don't have any idea what programming language most of the software I use is written in. If it's faster or more stable than tmux, shouldn't that be what's advertised, rather than implementation details? Reading the page, what catches my eye is the webasm plugin system (although it's not…

> Shouldn't that be completely opaque to the user? That would have been nice indeed. However many languages use lots of memory and are a bit slow, or are security-dangerous like C. It's nice to know, then, that this app likely uses barely any memory at all, and is as fast & keyboard-responsive as it can be, and harder to hack — Rust. (Assuming it is implemented in a good way :- ))

If it's faster or uses less memory, that's something that can be easily measured.

If it's more secure, that's harder to measure. But that's not even the tagline, just that it's written in Rust.

Re: Zellij – A Terminal Workspace and Multiplexer

#193
post #150

I see a lot of projects on here where the tagline is that they're written in Rust. Shouldn't that be completely opaque to the user? I don't have any idea what programming language most of the software I use is written in. If it's faster or more stable than tmux, shouldn't that be what's advertised, rather than implementation details? Reading the page, what catches my eye is the webasm plugin system (although it's not…

I feel like this stuff should be posted in a Rust-specific site, not on HN.

Re: Zellij – A Terminal Workspace and Multiplexer

#194
post #158

Earlier quoted context omitted.

Keybindings are a hard problem. Doubly so when you're a wrapper that has to also not collide with everyone else's keybindings. :) The idea was that users should spend most of their time in "normal" mode, deferring to "locked" mode only for cases like you mentioned (ctrl-r in bash or in vim). The modal ergonomics are built on that. I'd ideally like to find one word that describes locked mode better than "locked", whic…

ctlr+r is a very heavily used shortcut for some people. Perhaps that can be configurable?

All of the shortcuts are configurable: https://zellij.dev/documentation/keybindings.html

Re: Zellij – A Terminal Workspace and Multiplexer

#195
post #188

To me, tmux is unbeatable. Except for 2 things: - session-in-session is not built-in (but running a tmux from inside tmux does work) - resurrect (I.e rebuilding a complete multiplexing session out of nowhere, with running pieces of software, history, etc).

I'll be proving the point that tmux is a batteries-not-included program with my solution to your "resurrect", but it's probably fine for (and unsurprising to) anyone who doesn't mind writing a few lines of bash:

I have a bash script by the name of .tmux inside of every workspace folder. Its contents are typically a single multiline tmux command that creates a new tmux session with all the screens and processes relevant to the project (usually: emacs, shell for git, ssh to staging + prod, prompts in various databases, and several entr-driven screens for automatically running migrations, tests, etc).

Separately, I have a shell function that runs every time I change directories that checks for the existence of said file, and then either runs the file, attaches to the existing tmux session associated with the folder, or does nothing (in the case that the shell is already in a tmux session).

In short, I setup my workspace once per project.

Re: Zellij – A Terminal Workspace and Multiplexer

#196
post #167

Earlier quoted context omitted.

Oddly enough, almost nothing binds the space bar. I've been using ctrl-spc as my tmux prefix for years without a single conflict. I think this is because there is somewhat limited support for ctrl-space on older terminal emulators.

Also C-space sets the mark on Emacs.

I have been exposed as someone who doesn't use emacs :)

Re: Zellij – A Terminal Workspace and Multiplexer

#197
post #183

Earlier quoted context omitted.

Some would argue that Rust's advantages over C (or other languages) are so great that it constitutes a crucial feature of the software, and that while it doesn't necessarily indicate quality, it makes building quality software substantially easier.

Then shouldn't there be some observable (better yet, measurable) side effects?

True — one can certainly write terrible software in Rust, but in my view, being written in Rust is a notable enough aspect to a project to point it out

Re: Zellij – A Terminal Workspace and Multiplexer

#198

Earlier quoted context omitted.

>Shouldn't that be completely opaque to the user? No necessarely, because app being written in Rust and Go is actually a feature for the user, it means the entire app is a single executable with a decent runtime performance.

Not something most developers who may use a tmux equivalent would know about.

lol no, using tmux is a strong sign you would.

Re: Zellij – A Terminal Workspace and Multiplexer

#199
post #145
post #143

I've been using tmux for quite a while, though at a fairly casual level. The first thing I noticed is that this interface is discoverable - it shows me what I can do, which is incredible and makes me want to use it. The main reason I've been a casual tmux user and not an advanced one despite using it for years, is because every time I want to try something new I have to google if it's possible. The second thing I not…

You can lock the interface with ctrl-g and then all keys pass through.

I think ctrl r is used frequent enough to warrant a single keychord instead of having to chain though.

Re: Zellij – A Terminal Workspace and Multiplexer

#200
post #150

I see a lot of projects on here where the tagline is that they're written in Rust. Shouldn't that be completely opaque to the user? I don't have any idea what programming language most of the software I use is written in. If it's faster or more stable than tmux, shouldn't that be what's advertised, rather than implementation details? Reading the page, what catches my eye is the webasm plugin system (although it's not…

I've de-Rusted the title so hopefully the thread can stay on topic (i.e. specific, not generic: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor...).
Post reply on HN