Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zellij – A Terminal Workspace and Multiplexer

zellij.dev

Post reply on HN
Print view View original

181–190 of 248 posts

Re: Zellij – A Terminal Workspace and Multiplexer

#181

Post by mtrower »

ahepp wrote: 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…

In addition to what others have posted, it matters if you ever expect to read or modify the source. Assuming my capability requirements are met, I’m going to prefer a program written in a language that I’m comfortable with (such as C or lisp) to a program written in a language foreign to me (such as Go).

Re: Zellij – A Terminal Workspace and Multiplexer

#183

Post by ahepp »

door101 wrote: post #176
ahepp wrote: 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…

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?

Re: Zellij – A Terminal Workspace and Multiplexer

#184

Post by j1elo »

mikey_p wrote: post #96
j1elo wrote: post #87

Earlier quoted context omitted.

I never got this stance; JSON sucks for config files, because as a user, if there is anywhere that I need and am more thankful for comments, is in a configuration file. And TOML is maybe a good substitute for INI formats, but it doesn't really support nested data like JSON would, so suggesting to use TOML instead of JSON is misleading except for the simplest and most basic needs. If replacing JSON is the objective, I…

What about HOCON? https://github.com/lightbend/config/blob/master/HOCON.md

I guess why not? I mean, there are lots of options here. I prefer HJSON, also it helps a lot that its website does a very good job at convincing other fellow devs to try it...

But there is also JSON5, among the most popular alternatives. Then HOCON you mention, and probably a myriad more.

Re: Zellij – A Terminal Workspace and Multiplexer

#185

Post by ibraheemdev »

alpaca128 wrote: post #175
ibraheemdev wrote: post #147

Earlier quoted context omitted.

> I use a multiplexer because it lets me instantly open a new terminal in the same directory I'm currently working in. You can add a keybinding for this with alacritty: { key: N, mods: Command, action: SpawnNewInstance } > Furthermore it can open the terminal's buffer in Vim, letting me select and copy text using all features and shortcuts I'm used to alacritty has vi mode which gives you all of those keybindings wit…

> alacritty has vi mode which gives you all of those keybindings It doesn't give me access to my custom keybindings or the plugins I have setup in Vim. Also I can't select or annotate terminal output and then save it directly into a file in one step. The multiplexer is both more powerful and flexible by actually doing less and just passing tasks like selection and copying to other proven tools. I appreciate that more…

Well, I'm not sure why you need vim plugins for copy-pasting from the terminal, but I agree that it is more powerful. My point is that a lot of people don't need tmux/zellij because their terminal emulators provide much of the useful functionality.

Re: Zellij – A Terminal Workspace and Multiplexer

#186

Post by ahepp »

OhSoHumble wrote: post #180
ahepp wrote: 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…

It's a technical post on a technical forum filled with technical people. We aren't just users, we're programmers. It makes sense to include broad implementation details in the title.

Maybe a fair point, I guess it's ambiguous because technical people are both the users and developers of terminal multiplexers.

I do still question what it means if the coolest thing to say about it is it was written in Rust, whether that's intended for developers or for users

Re: Zellij – A Terminal Workspace and Multiplexer

#187

Post by dflock »

somethingwitty1 wrote: post #169
IshKebab wrote: post #118

Earlier quoted context omitted.

I agree that TOML sucks for nested structures. JSON5 is probably the best option at the moment. https://json5.org/ * Instantly obvious what the structure is (unlike YAML or TOML). * Everyone knows JSON already. This just makes it a bit nicer. * No noob security mistakes or type confusion caused by underquoting like YAML.

Don't forget the truncation problem with YAML/TOML. A partially read/transmitted YAML/TOML file is often still considered valid.

That also makes it really easy to concatenate them, either `cp a.yaml + b.yaml c.yaml` or just `cat a.yaml >> b.yaml` - which is quite nice, compared to trying to do this with JSON etc... files.

Re: Zellij – A Terminal Workspace and Multiplexer

#188

Post by lolive »

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

Re: Zellij – A Terminal Workspace and Multiplexer

#189

Post by ehsanu1 »

imsnif wrote: post #158
uses wrote: post #149

Earlier quoted context omitted.

See that's also interesting, thanks for the heads up. I saw "lock" previously and pressed it, and it did something besides what I expected. When I think lock, I think it's literally locking the interface in some way so someone can't interact with the software, including myself unintentionally. That's what it means in Windows, MacOS, and even tmux. I would consider just starting out "locked" but change the paradigm. I…

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?

Re: Zellij – A Terminal Workspace and Multiplexer

#190

Post by emteycz »

ahepp wrote: post #186
OhSoHumble wrote: post #180

Earlier quoted context omitted.

It's a technical post on a technical forum filled with technical people. We aren't just users, we're programmers. It makes sense to include broad implementation details in the title.

Maybe a fair point, I guess it's ambiguous because technical people are both the users and developers of terminal multiplexers. I do still question what it means if the coolest thing to say about it is it was written in Rust, whether that's intended for developers or for users

The coolest thing to say about it is "Terminal Workspace and Multiplexer" which precedes "Written in Rust". What more would you add? I think that's cool enough!
Post reply on HN