Zellij – A Terminal Workspace and Multiplexer(zellij.dev)
zellij.dev
Zellij – A Terminal Workspace and Multiplexer
http://zellij.dev/news/beta#
247 comments
> The second thing I noticed is that it uses ctrl-r as a core shortcut. Mega problem: ctrl-r is a built-in bash feature which I use every day to recall previous commands. This makes me think I can't use this tool at all.
In fairness, ctrl-a (screen default) and ctrl-b (tmux default) are also super useful readline shortcuts in bash (c-a = go to beginning of line, c-b = back one character).
EDIT: Sorry, I just realized - ctrl-r isn't a prefix, it's a shortcut, isn't it? And they have lots more? Yeah, that's ... a pretty questionable approach; it'll interfere with lots of things.
In fairness, ctrl-a (screen default) and ctrl-b (tmux default) are also super useful readline shortcuts in bash (c-a = go to beginning of line, c-b = back one character).
EDIT: Sorry, I just realized - ctrl-r isn't a prefix, it's a shortcut, isn't it? And they have lots more? Yeah, that's ... a pretty questionable approach; it'll interfere with lots of things.
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 :)
Sadly for CJK users, C-space is used to trigger the input methods in some operating systems, e.g., MS Windows
This is a very good one! I've used it for a while before discovering I prefer to use ctrl-spc to trigger intellisense in neo vim.
> Ctrl-b is what tmux uses, so you know it's safe
Ctrl-b is "back one character" in most apps that use readline (including bash) and emacs.
For that reason I change my Tmux prefix to Ctrl+Y (I also think it is more ergonomic).
Ctrl-b is "back one character" in most apps that use readline (including bash) and emacs.
For that reason I change my Tmux prefix to Ctrl+Y (I also think it is more ergonomic).
But Ctrl+Y is what I use to scroll up in vim!
Ultimately I think all ctrl combinations were taken long before tmux came around, you just set it to the one that annoys you less.
Ctrl+a seems to be a popular choice. I personally just leave it on the default.
C-b is what tmux uses because it was developed in screen and and C-a was taken. I always change my tmux config to C-a leader and C-a-a for literal C-a
C-y is yank though (in both emacs and readline); I definitely use yank more than C-b.
I switched my .screenrc to use ^O as the escape key; in vim insert mode it's "take the next keystroke(s) from the normal mode keymap" so you can `^O d t $` from insert mode to delete up the end of the line or whatever. I never use that in vim. I don't even remember what exactly it does in emacs, something that inserts a newline. In readline I think it's "accept-and-...something-else", that I also never use.
I usually run a single actual terminal, running a "meta" screen session, with one sub-screen session for each project or environment. The outer screen uses ^Z as the escape key because I hardly ever use this for she'll job control (I have ~infinity screen windows, after all).
I switched my .screenrc to use ^O as the escape key; in vim insert mode it's "take the next keystroke(s) from the normal mode keymap" so you can `^O d t $` from insert mode to delete up the end of the line or whatever. I never use that in vim. I don't even remember what exactly it does in emacs, something that inserts a newline. In readline I think it's "accept-and-...something-else", that I also never use.
I usually run a single actual terminal, running a "meta" screen session, with one sub-screen session for each project or environment. The outer screen uses ^Z as the escape key because I hardly ever use this for she'll job control (I have ~infinity screen windows, after all).
You can lock the interface with ctrl-g and then all keys pass through.
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. It's not locked, it's just that the menu isn't active. "Unlocking" now becomes enabling the menu/interface - until you disable the menu.
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", which I agree is not ideal. I spent quite some time thinking about it and asking others, but most of us are not native English speakers - so maybe there's something obvious we're missing. :)
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", which I agree is not ideal. I spent quite some time thinking about it and asking others, but most of us are not native English speakers - so maybe there's something obvious we're missing. :)
Wouldn't the word "passthrough" be the right word for this feature?
That's a cool idea! I'll run it by some old/new users, see how they react. Thanks!
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
I think ctrl r is used frequent enough to warrant a single keychord instead of having to chain though.
Regarding the prefix key, I agree CTRL+R may not be the best default choice.
But if it is easy to change then I think it is OK.
One of the first things I do on a new system with tmux is remap CTRL+B to CTRL+A, as a screen hangover and I think it is more ergonomic anyway.
Though it means I've completely given up using CTRL+A / CTRL-X for incrementing / decrementing numbers in vim.
I can't think of any programs that have an important use for CTRL-B, that's the tradeoff between uniqueness and usability I guess.
I don't think there will be a choice to keep everyone happy or that is totally conflict free.
But if it is easy to change then I think it is OK.
One of the first things I do on a new system with tmux is remap CTRL+B to CTRL+A, as a screen hangover and I think it is more ergonomic anyway.
Though it means I've completely given up using CTRL+A / CTRL-X for incrementing / decrementing numbers in vim.
I can't think of any programs that have an important use for CTRL-B, that's the tradeoff between uniqueness and usability I guess.
I don't think there will be a choice to keep everyone happy or that is totally conflict free.
I love that the UI can be explored by the user, since it shows available keyboard shortcuts. This is something where GNU screen or tmux suck, because you really have to lookup how to operate these tools. In some manual or with google.
Yes, I think more than "written in Rust", what is attractive about these tools (and other Unix replacements like Ripgrep, FZF) is more their attitude of "we have a lot more computing power and higher resolution/larger screens now. let's have saner defaults, intuitive UIs or larger search spaces (in case of FZF) to actually take advantage of that."
I will say that one aspect of "written in Rust" is the combination of a high performance language (giving more head room for adding features) and a great packaging story (so you can build on the shoulders of giants, like burntsushi, author of ripgrep).
I had to print this
https://tmuxcheatsheet.com/
https://tmuxcheatsheet.com/
fwiw, if youre in tmux you can hit <prefix>-?, so for me it's ctrl+w+? and itll show all available tmux commands.
tmux and screen both have online shortcut “cheat sheet” displays, fyi.
I'm not sure I could untrain all my muscle memory I've built up over the years with my TMUX configuration, but I truly believe in the next 10 years all of my current command line tools will be slowly replaced with rust equivalents (with the exception of neovim). ripgrep and fzf are already a large part of my workflow, and I love seeing WebAssembly becoming the universal plug and play standard.
> Build a web client to allow users to connect to a running Zellij daemon through the browser (on a local or remote server).
That's the future feature I'm most interested in over TMUX.
> Build a web client to allow users to connect to a running Zellij daemon through the browser (on a local or remote server).
That's the future feature I'm most interested in over TMUX.
> I'm not sure I could untrain all my muscle memory I've built up over the years with my TMUX configuration
You could quite easily configure Zellij's keybindings [0] to mirror your tmux config.
[0]: https://zellij.dev/documentation/keybindings.html
You could quite easily configure Zellij's keybindings [0] to mirror your tmux config.
[0]: https://zellij.dev/documentation/keybindings.html
That's great! As soon as it supports detaching a running session I'll take a look at migrating.
Here's the tracking issue for that: https://github.com/zellij-org/zellij/issues/69
Looks like it'll be coming relatively soon (there's already a PR open, although it needs some refinement)
Looks like it'll be coming relatively soon (there's already a PR open, although it needs some refinement)
You can use abduco for that part (but I’ll just keep using tmux).
I believe you could. I can share the story from a bit different field. I was using a split keyboard with staggered layout and just built an Ergodox because wanted to try vertically staggered layout. Another differences are thumb clusters of keys on Ergodox and different firmware. So the layouts of both keyboards are very different and different customisations can be made.
The main thing which I was afraid of was the same as you've said - that I won't be able to change my muscle memory. Another thing - I won't be able to switch back the old keyboard (I expected to use it at the office) or even won't be able to use laptop keyboard anymore.
Surprisingly even after getting comfortable with Ergodox with totally different layout (different firmware is being used between keebs) I'm still able to jump between those easily. Maybe the first 5 mins are a bit harder but that is it. This surprises me what human brain is capable to do. Of course I still need to switch between keyboards regularly to not forget the layouts.
Not the same thing but we often are afraid of unknown.
The main thing which I was afraid of was the same as you've said - that I won't be able to change my muscle memory. Another thing - I won't be able to switch back the old keyboard (I expected to use it at the office) or even won't be able to use laptop keyboard anymore.
Surprisingly even after getting comfortable with Ergodox with totally different layout (different firmware is being used between keebs) I'm still able to jump between those easily. Maybe the first 5 mins are a bit harder but that is it. This surprises me what human brain is capable to do. Of course I still need to switch between keyboards regularly to not forget the layouts.
Not the same thing but we often are afraid of unknown.
> I'm not sure I could untrain all my muscle memory I've built up over the years with my TMUX configuration
I assume you can customize your keybindings so that they're mostly the same as your TMUX configuration.
But even if you couldn't, based on my own experience changing editors/OS/other tools, if you commit to it, retraining should take a couple weeks at most. It'll be super annoying for that couple weeks but it's really not all that ingrained.
I assume you can customize your keybindings so that they're mostly the same as your TMUX configuration.
But even if you couldn't, based on my own experience changing editors/OS/other tools, if you commit to it, retraining should take a couple weeks at most. It'll be super annoying for that couple weeks but it's really not all that ingrained.
I'm curious, why is in-browser use so appealing to you?
Personally I have a TMUX session on a pi4 I keep up that just monitors various services and there's times I'd like to be able to open it not unlike a dashboard on my phone or tablet. Using a session via the web is not a big use case for me, or something I'd want to operate exclusively in, but it'd be nice to have.
If you're already spending a lot of time in the browser looking at stuff (AWS Console, Stack Overflow, etc), I can see the convenience of just switching tabs to your terminal rather than pulling up a window.
So far I've solved that problem with keyboard shortcuts or other macros to pull up a terminal when I need it.
So far I've solved that problem with keyboard shortcuts or other macros to pull up a terminal when I need it.
Conceptually, I don't think the solution to "switching windows is too hard" ought to be "make the terminal part of the browser". Although it does seem like perhaps the least immediately painful way to solve the problem.
Using Lynx in the terminal might be another way to do it.
Using Lynx in the terminal might be another way to do it.
Yeah, I tend to agree. But I know that there are some people who really, really, really like doing stuff in the browser.
I think getting the terminal into the browser is exactly the way this should be solved. Currently I'm in a browser for the vast part of my work, as are a huge lot of other people. Most of the web apps I need wouldn't even render in Lynx.
Why not have your software be universally accessible & online? What is the appeal in having software that is attached to a single system, single OS, & offline?
[deleted]
This seems like a very baroque alternative to tmux and ssh
Let's consider: I'm at my parents, or a friends house. I need to log in to do something. My options are:
A) download a terminal emulator + ssh application onto their computer & run that, flooding the screen with some unknown terminal application.
B) opening a web page & logging in to a Zellij or TermKit or whatever session.
Which do you think will seem more baroque to them? The web is an obvious, much improved way to do almost all software. It's online, universally accessible. A lot of stuck, old-fashioned-thinking in this thread. I'm a ssh + tmux (or more often ssh + dtach/vim) user myself, but it's clear to me this has serious disadvantages, that it's not nearly as accessible, as on tap as it could be.
A) download a terminal emulator + ssh application onto their computer & run that, flooding the screen with some unknown terminal application.
B) opening a web page & logging in to a Zellij or TermKit or whatever session.
Which do you think will seem more baroque to them? The web is an obvious, much improved way to do almost all software. It's online, universally accessible. A lot of stuck, old-fashioned-thinking in this thread. I'm a ssh + tmux (or more often ssh + dtach/vim) user myself, but it's clear to me this has serious disadvantages, that it's not nearly as accessible, as on tap as it could be.
FZF is written in Go though.
[deleted]
Check out tmate
The idea of using WebAssembly for their plugins is really impressive (they are using Wasmer!). It allows to have fully sandboxed code that interact with their code safely and fast.
I think more projects will start following the same direction soon!
I think more projects will start following the same direction soon!
I'm confused. Zellij uses wasmer and wasmer-wasi. Wasmer may use cranelift for compilation (dont know if Zellij does).
"Fast & Safe. Wasmer runs WebAssembly at near-native speed in a fully sandboxed environment." (https://github.com/wasmerio/wasmer)
But ...
"Cranelift does not yet perform mitigations for Specter or related security issues, though it may do so in the future." (https://github.com/bytecodealliance/wasmtime/tree/main/crane...)
Will the wasmer runtime handle specter / meltdown / rowhammer attacks?
"Fast & Safe. Wasmer runs WebAssembly at near-native speed in a fully sandboxed environment." (https://github.com/wasmerio/wasmer)
But ...
"Cranelift does not yet perform mitigations for Specter or related security issues, though it may do so in the future." (https://github.com/bytecodealliance/wasmtime/tree/main/crane...)
Will the wasmer runtime handle specter / meltdown / rowhammer attacks?
It doesn't, nor does it use seccomp to mitigate against language VM security issues.
seccomp should not be needed for a Wasm VM unless the host calls are unsafe, which is not the case by default (since no host functions are provided) or for WASI (since is alreay designed to be sandboxed).
Also, seccomp only works in the Linux kernel (not in Windows, or macOS)... so it's a no-go for a universal sandboxed VM :)
Also, seccomp only works in the Linux kernel (not in Windows, or macOS)... so it's a no-go for a universal sandboxed VM :)
I feel like in this case those kinds of things are up to Zellij. If you run wasmer within the same process and share memory with the main Zellij process then yes wasmer/cranelift/wasmtime/wasm doesn't protect you from various speculative execution attacks. However, Zellij could run plugins in separate processes and apply things like seccomp to get further protections provided at the operating system level.
This is still not a complete security story and would not provide the same kind of protection as a VM, but I think the charitable take here is that this is a good sandboxing tool and a step in the right direction for something like a plugin system.
edit: I also disagree with the "fully sandboxed" wasmer line, but wasmer is a venture-backed for-profit org that will start selling something at some point and they might have a motivation to blur the lines a little. I appreciate cranelift's more honest disclaimer.
This is still not a complete security story and would not provide the same kind of protection as a VM, but I think the charitable take here is that this is a good sandboxing tool and a step in the right direction for something like a plugin system.
edit: I also disagree with the "fully sandboxed" wasmer line, but wasmer is a venture-backed for-profit org that will start selling something at some point and they might have a motivation to blur the lines a little. I appreciate cranelift's more honest disclaimer.
WASM and Wasmer are not intrinsically anymore secure, except for simplicity, than any other editor plugin system. Vimscript and Emacs-lisp basically have the same security characteristics as using WASM for plugins. It's not a step in any direction, except for whatever environment Zellij exposes to the plugins by default.
I'm not sure how this is true. I don't know anything about vimscript and emacs-lisp plugin systems, but at a cursory glance it looks like plugins might be able to do things like launch shell commands?
Zellij seems to be using WASI, a standard set of syscalls. Currently, wasi syscalls (or at least the version of wasi that is running in wasmer) can't really access the network, can't fork/exec, can provide a chroot view of the filesystems (without root access), can limit access to certain types of functionality. These kind of secure defaults seem like an improvement to me compared to most plugin systems I'm familiar with.
Maybe vimscript/emacs-lisp has these things.
Zellij seems to be using WASI, a standard set of syscalls. Currently, wasi syscalls (or at least the version of wasi that is running in wasmer) can't really access the network, can't fork/exec, can provide a chroot view of the filesystems (without root access), can limit access to certain types of functionality. These kind of secure defaults seem like an improvement to me compared to most plugin systems I'm familiar with.
Maybe vimscript/emacs-lisp has these things.
[deleted]
Can you elaborate on the threat model that requires your terminal multiplexer to have rowhammer mitigations?
I think OP is just arguing and saying "fully sandboxed" might imply that kind of security.
Yes, maybe Zellij using Wasmer is great, don't know. I commented because as someone who don't follow the rust ecosystem I was curious if there was something not as big and complicated as google's v8 engine for running sandboxed code.
But it seems you should not use wasmer for running untrusted code or binaries.
I also don't know enough about rowhammer, or security exploit of any kind really, to answer the question about how you could use them against a terminal multiplexer.
But it seems you should not use wasmer for running untrusted code or binaries.
I also don't know enough about rowhammer, or security exploit of any kind really, to answer the question about how you could use them against a terminal multiplexer.
I've only used it for a few minutes, but here's my first impressions.
What I really liked: I didn't have to read any documentation to understand how to do the things I'm used to in tmux, the CTRL+[KEY] menus with hints are really helpful and well designed.
What I didn't like so much: The interface doesn't feel as snappy as tmux over a remote connection, and I couldn't find any way in the "CTRL-menu" to detach (like tmux CTRL+B,D)
Looking forward to future releases!
What I really liked: I didn't have to read any documentation to understand how to do the things I'm used to in tmux, the CTRL+[KEY] menus with hints are really helpful and well designed.
What I didn't like so much: The interface doesn't feel as snappy as tmux over a remote connection, and I couldn't find any way in the "CTRL-menu" to detach (like tmux CTRL+B,D)
Looking forward to future releases!
From the webpage, it seems ability to detach is planned for future work.
I noticed your second point. Massive type ahead, whether at the shell prompt, or within an app. I could not touch type at that delay, like trying to talk over a call with a pronounced delayed echo.
What's the point of fitting multiple terminals in a single text-mode screen when everybody is using GUI terminal emulators and tiling window managers?
I remember good old pure text-mode days with warmth but doubt there are many people actually doing it nowadays. So I imagine this (thesubject) is going to be ran inside a GUI terminal emulator window and I don't understand how is that better than just having more windows.
I remember good old pure text-mode days with warmth but doubt there are many people actually doing it nowadays. So I imagine this (thesubject) is going to be ran inside a GUI terminal emulator window and I don't understand how is that better than just having more windows.
I do most of my work (embedded development) ssh'd into a few linux boxen at the office which can reach my test devices and various other bits and bobs.
I'm pretty happy running full text mode editing in emacs (-nw, ftw :) and a few other shells for tasks I haven't incorporated into emacs yet. Speed is nice, even over a vpn, which running anything graphical is somewhat grim.
Still, the killer feature with screen multiplexers (in my case, tmux, but this isn't unique to tmux) for me is the fact that the tools preserve state, so I can start a long job and it won't be interrupted, even if the connection drops. I just log back in and reattach and everything is just like it was.
Sure there are other ways to do that, but having it neatly wrapped up and always on is really a game-changer for me.
I'm pretty happy running full text mode editing in emacs (-nw, ftw :) and a few other shells for tasks I haven't incorporated into emacs yet. Speed is nice, even over a vpn, which running anything graphical is somewhat grim.
Still, the killer feature with screen multiplexers (in my case, tmux, but this isn't unique to tmux) for me is the fact that the tools preserve state, so I can start a long job and it won't be interrupted, even if the connection drops. I just log back in and reattach and everything is just like it was.
Sure there are other ways to do that, but having it neatly wrapped up and always on is really a game-changer for me.
That's a good question and I think it depends on the developer. One recent day I became fed up managing my three separate terminal windows with each having a few tabs. I thought "alright, now's a great time to jump into a multiplexer" and it worked well as a catalyst. I downloaded Tmux, set a Tmux shortcut browser window for easy reference, and mimicked my setup in Tmux.
It's immensely a cleaner solution than toying around with separate windows for me. Switching sessions and consoles is seamless and it's all in one window. Eventually something will bite me regarding Tmux getting in the way of something and causing headaches but the momentum I have is great.
I suggest trying one out sometime, it may open a whole new world of tooling for you! Otherwise there's no sweat if you got something working sans multiplexer.
It's immensely a cleaner solution than toying around with separate windows for me. Switching sessions and consoles is seamless and it's all in one window. Eventually something will bite me regarding Tmux getting in the way of something and causing headaches but the momentum I have is great.
I suggest trying one out sometime, it may open a whole new world of tooling for you! Otherwise there's no sweat if you got something working sans multiplexer.
Anecdata:
I don't want to tile all my windows, only terminals, so I'm not interested in tiling WM.
I also jump between OSs and appreciate being able to have the same terminal multiplexing behaviour on both linux and macOS, without needing to learn the keyboard shortcuts and idiosyncrasies of two different GUI terminal multiplexers.
As another commenter pointed out, being able to multiplex in the exact same way for remote sessions is a massive bonus.
Lastly, tmux has a lot of features and customization and once you learn those you really come to appreciate them. Tmux can also look really quite nice, it doesn't need to look as boring as it does out of the box: https://i.imgur.com/MgUx0U2.png.
I don't want to tile all my windows, only terminals, so I'm not interested in tiling WM.
I also jump between OSs and appreciate being able to have the same terminal multiplexing behaviour on both linux and macOS, without needing to learn the keyboard shortcuts and idiosyncrasies of two different GUI terminal multiplexers.
As another commenter pointed out, being able to multiplex in the exact same way for remote sessions is a massive bonus.
Lastly, tmux has a lot of features and customization and once you learn those you really come to appreciate them. Tmux can also look really quite nice, it doesn't need to look as boring as it does out of the box: https://i.imgur.com/MgUx0U2.png.
If that's a screenshot of your setup do you mind sharing your config? :)
> but doubt there are many people actually doing it nowadays
I use tmux almost as much as bash. And if you use a Mac with Iterm2, you can use tmux the way you're imagining.
The primary advantage is the same reason I still use vim a lot - speed and efficiency. There is just no comparison to GUI tooling. But I readily admit a lot of it is familiarity - I know and like my tools, and there's no advantage gained by changing.
I use tmux almost as much as bash. And if you use a Mac with Iterm2, you can use tmux the way you're imagining.
The primary advantage is the same reason I still use vim a lot - speed and efficiency. There is just no comparison to GUI tooling. But I readily admit a lot of it is familiarity - I know and like my tools, and there's no advantage gained by changing.
I use a tiling window manager and use tmux - just because I can tile windows doesn't negate my use of tmux.
I have a single window that is all of my terminals - which to me is much easier to manage than a load of random terminals all over the place. Sessions are named, and windows are named, and I have F1-F8 mapped to load the corresponding window, F10 brings up a list of sessions, and F9 toggles between the last 2 sessions.
Mine is based on https://github.com/gpakosz/.tmux but customised for F keys, status bar, mouse etc
I have a single window that is all of my terminals - which to me is much easier to manage than a load of random terminals all over the place. Sessions are named, and windows are named, and I have F1-F8 mapped to load the corresponding window, F10 brings up a list of sessions, and F9 toggles between the last 2 sessions.
Mine is based on https://github.com/gpakosz/.tmux but customised for F keys, status bar, mouse etc
Remote sessions. Unless you want to use X forwarding, or create multiple SSH sessions, it's way more ergonomic to do it this way. I currently use tmux for this and when you combine it w/ the tmux command mode (-CC) and iTerm 2 you get the best of both worlds, but even without iTerm 2 integration I still prefer panes to be handled by the multiplexer because then I know I can get my consistent and comfortable environment on any arbitrary remote box.
You can multiplex your SSH session and have several ssh commands running on the same connection (without having to type the password/check the security key again). Check the ControlMaster option for SSH.
And this is better than tmux... Why?
I use both. The primary reason for ControlMaster in my case is we use 2FA, and this way I only have to auth one connection.
Tmux is the UI for switching between ssh sessions sharing the connection.
Tmux is the UI for switching between ssh sessions sharing the connection.
I'm a heavy terminal user, and I cannot understand how people use something like tmux that constantly causes full screen refreshes and hangs due to one part misbehaving.
Are you saying that tmux feels slow on the terminal? If that is the case maybe using different terminal might help. I'm fan of `st` terminal because of its speed. And haven't noticed any slowness of tmux.
I use tmux/screen when I am working via SSH for some reason. It's nicer to create the layout in a terminal multiplexer rather than having multiple SSH sessions, because if you ever lose connection or your laptop dies, everything is like you left it.
Locally, I don't bother and just use i3.
Locally, I don't bother and just use i3.
I use tmux locally even though I run i3 as my window manager. Mostly because I configured tmux to show the current directory and git branch (if in a git directory) so I can keep my prompt a clean "$".
My trick is all the directory, date, git junk in my prompt is separated by a newline and then $, so when I copy and paste my shell somewhere, I can just drop those lines easily without having to do fine selection.
That seems like a lot of wasted space to me. The benefit of putting it into tmux is it only shows in 1 place. I don't need to see the git branch and folder of the location where I ran my previous commands, I just need to see where I am at right now.
Seeing the old time is useful though because it lets you eyeball how long a command took to run even if you forgot to do `time`.
Do you ever need to know how long a command takes? And if you ever need it is it really worth a full line for every command that is ran. And it shows the time that the prompt is printed right? It doesn't show the time your command is executed if I am correct.
I guess you can hit enter before every command is entered to get the correct time but that is a lot of wasted space!
Maybe I'm getting too minimalist but I don't see the benefit to productivity in these over the top prompts.
I guess you can hit enter before every command is entered to get the correct time but that is a lot of wasted space!
Maybe I'm getting too minimalist but I don't see the benefit to productivity in these over the top prompts.
Not knocking your setup but you can have can configure most terminal emulators to put that info in the title and have that displayed on your bar.
I use i3 and the Simple Terminal (ST) so no titles and no bars for me.
If anyone is curious what it looks like: https://imgur.com/Xx19sFn.png
If anyone is curious what it looks like: https://imgur.com/Xx19sFn.png
Not having to touch the mouse. I can't do it myself, but I've watched ops folks using tmux in a productive way that I think would be difficult to reproduce if you involved a window manager.
You don't have to use the mouse with tiling window managers...
/s heavy tmux user that left it for xmonad.
/s heavy tmux user that left it for xmonad.
Can you select and copy some text from your terminal emulator without using tmux? Copy-mode is one of the killer features of tmux for me.
The only terminal emulator that supports selection with keyboard afaik is rxvt with plugins. I would be interested to know if there are other terminals that support this. Please don't say emacs XD
The only terminal emulator that supports selection with keyboard afaik is rxvt with plugins. I would be interested to know if there are other terminals that support this. Please don't say emacs XD
You can use any terminal emulator you want with tiling window managers...I don't see the issue.
Run rxvt if you like.
Run rxvt if you like.
Yeah, I think that the main benefit of tmux is session management. Tiling window managers can replace tmux panes.
Tiling window managers cannot replace a multiplexer's knowledge about the session.
I use a multiplexer because it lets me instantly open a new terminal in the same directory I'm currently working in. 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. Doing the same by scrolling around, selecting snippets using the mouse and pressing Ctrl-Shift-C cannot compete with that.
Yes, there are a few terminal emulators with integrated tabs and window splitting and all that which offer similar features, but then they also have countless other things I don't need and in return take ten times longer to open a new window.
I use a multiplexer because it lets me instantly open a new terminal in the same directory I'm currently working in. 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. Doing the same by scrolling around, selecting snippets using the mouse and pressing Ctrl-Shift-C cannot compete with that.
Yes, there are a few terminal emulators with integrated tabs and window splitting and all that which offer similar features, but then they also have countless other things I don't need and in return take ten times longer to open a new window.
> 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:
alacritty has vi mode which gives you all of those keybindings without having to open vim (ctrl+shift+space).
You can add a keybinding for this with alacritty:
{ key: N, mods: Command, action: SpawnNewInstance }
alacritty has vi mode which gives you all of those keybindings without having to open vim (ctrl+shift+space).
> 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 than terminals trying to do everything.
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 than terminals trying to do everything.
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.
Aye. Occasionally I'll pop tmux open in a tile for this purpose.
It's been reduced to merely being a replacement for screen for me.
It's been reduced to merely being a replacement for screen for me.
I don't know a single developer that actually stuck with tiling window managers. I know a ton who use kitty or tmux in their terminal of choice.
gui terminals crash. tmux is forever.
About 90% of my work is remote sessions.
The discoverability of shortcuts in zellij is great! Besides this and tmux you can also try
* mtm: https://github.com/deadpixi/mtm
* dvtm: https://linuxconfig.org/an-introduction-to-terminal-multiple...
* abduco
None of these have ever stuck with me because I don't like how they alter the ability to scroll (although I haven't tried the newer tmux mouse/scrolling capabilities).
To maintain a session I prefer to use EternalTerminal (screen messes up scrolling much like tmux).
I find most of my windowing needs satisfied by tabs in the terminal and by using Xmonad on Linux or yabi on Mac whereas some Mac users seem to be at least partially making up for the lack of window management with tmux.
I just switched to using wezterm as my daily terminal. It is written in Rust, very fast, featureful, and works cross platform.
* mtm: https://github.com/deadpixi/mtm
* dvtm: https://linuxconfig.org/an-introduction-to-terminal-multiple...
* abduco
None of these have ever stuck with me because I don't like how they alter the ability to scroll (although I haven't tried the newer tmux mouse/scrolling capabilities).
To maintain a session I prefer to use EternalTerminal (screen messes up scrolling much like tmux).
I find most of my windowing needs satisfied by tabs in the terminal and by using Xmonad on Linux or yabi on Mac whereas some Mac users seem to be at least partially making up for the lack of window management with tmux.
I just switched to using wezterm as my daily terminal. It is written in Rust, very fast, featureful, and works cross platform.
Tab-rs is another rust terminal multiplexer[1].
[1] https://github.com/austinjones/tab-rs
[1] https://github.com/austinjones/tab-rs
The resizing algorithm looks cool: panes are no longer in a grouped hierarchy of vertical and horizontal splits, as in tmux or vim, and pretty much every other customizable layout tool. In a grid of four squares, a corner can either be resized in either direction and only modify one other pane. (It's hard to explain; it's shown in the demo gif.) I wonder if you can make "holes"...
Rearranging a layout with more than 3 panes in tmux or vim is always difficult. In tmux it's at least easy to swap panes (C-prefix '{' or '}'), but vim doesn't have any simple way to do something similar. I wonder if Zellij's approach makes it any easier. Maybe it's a UX pattern that is made easier with a mouse.
Rearranging a layout with more than 3 panes in tmux or vim is always difficult. In tmux it's at least easy to swap panes (C-prefix '{' or '}'), but vim doesn't have any simple way to do something similar. I wonder if Zellij's approach makes it any easier. Maybe it's a UX pattern that is made easier with a mouse.
A few months ago, I swapped my iTerm with Alacritty (another Rust based project) and have been really happy with how snappy it is. I highly recommend it. Looking forward to trying this as a replacement for my tmux setup. I like the idea of being able to hack on wasm modules. Will there be matching key bindings for Tmux?
Interestingly, about an hour ago, I was looking into Alacritty to replace iTerm (because of how slow it feels!). I use tmux as well and seeing this project made me wonder if I should test out Alacritty + Zellij!
Alacritty is great, it feels very snappy and it can auto-reload the configuration(with a few exceptions), so you can quickly try out different settings without restarting the program all the time.
I switched to st because Alacritty still has no ligature support, but aside from that limitation it's definitely my favorite.
I switched to st because Alacritty still has no ligature support, but aside from that limitation it's definitely my favorite.
I personally can't stand not having multiple tabs. Plus, it is fast, but it is not the "fastest" as it falsely claims. I prefer MacOS's default terminal.app over it.
Looks amazing!
Unfortunately it doesn't implement the feature that keeps me stuck on Terminator: disabling of line wrapping. After using that I could never use a different terminal. But perhaps this could inspire me to try and learn enough Rust to implement it :-)
Unfortunately it doesn't implement the feature that keeps me stuck on Terminator: disabling of line wrapping. After using that I could never use a different terminal. But perhaps this could inspire me to try and learn enough Rust to implement it :-)
Lots of mentions of tmux but none yet of tmuxinator: https://github.com/tmuxinator/tmuxinator
Lets you predefine layouts and what will run in each pane.
Lets you predefine layouts and what will run in each pane.
Related question:
What’s the state of the art for managing the running of, and the output from, multiple CLI commands at once? Say I have a task D that requires a task A, B, and C, but for which A and B and independent.
The naive solution (let the output interlace and just watch the exit codes) creates a substantial comprehension problem for my coworkers, so I don’t usually do it. But over and over again I find myself having a 20-90 second inefficiency or two caused by running two tasks that have to complete but the order doesn’t matter.
What’s the state of the art for managing the running of, and the output from, multiple CLI commands at once? Say I have a task D that requires a task A, B, and C, but for which A and B and independent.
The naive solution (let the output interlace and just watch the exit codes) creates a substantial comprehension problem for my coworkers, so I don’t usually do it. But over and over again I find myself having a 20-90 second inefficiency or two caused by running two tasks that have to complete but the order doesn’t matter.
I don't know about state of the art, but you can pretty easily script tmux to launch, split windows/panes, run commands in each pane, and log and exit the session on completion.
This is fantastic! Love the customization. I think for this level of complexity YAML is fine. Are there any plans to incorporate the plug in system which tmux has through tpm?
I have messed with tmux in the past, but could never remember all the gibberish sequences to make it useful.
Thought I would take a look at this. Like the presentation of all the actions. TAB control was nice and all that.
But what is with the crazy input character delay? Not much fun for touch typing when I can get ahead of the input buffer by four or five keys (without really trying). I have never noticed that on tmux.
Is anyone else seeing this?
Thought I would take a look at this. Like the presentation of all the actions. TAB control was nice and all that.
But what is with the crazy input character delay? Not much fun for touch typing when I can get ahead of the input buffer by four or five keys (without really trying). I have never noticed that on tmux.
Is anyone else seeing this?
Is there a good reason for a multiplexer to be a separate tool from a terminal? Or a window manager? Or is this just GNU/Unix philosophy (do one thing well and compose).
The reason I ask is that while I never used a multiplexer like tmux, I use the layout features of kiTTY every day and I can't quite see beyond that common use case (split this terminal into X windows with Y layouts).
The reason I ask is that while I never used a multiplexer like tmux, I use the layout features of kiTTY every day and I can't quite see beyond that common use case (split this terminal into X windows with Y layouts).
persistence and the ability to run it on a remote machine are the big draws. I can set up a tmux session on a remote box, have multiple connections to it, and close my terminal without losing my work.
Makes sense.I am definitely not SSH ing around very much.
Seems muxers are essential for more ops / infrastructure facing workloads
Seems muxers are essential for more ops / infrastructure facing workloads
This looks incredible to someone who's always had an eye for tmux but not the energy to spend two weeks memorizing keybindings.
As a side note, does anyone know why it fails to load the separators in the status bar on WSL? I've got a proper font installed and even emojis work. However with Zellij, I am just getting "" characters between the Ctrl + lines.
As a side note, does anyone know why it fails to load the separators in the status bar on WSL? I've got a proper font installed and even emojis work. However with Zellij, I am just getting "" characters between the Ctrl + lines.
I think the vertical resize of the "before" is the wrong one. Shouldn't it be also resizing the window next to it?
The first illustration shows how this works in tmux.
The illustration first has a split in left and right half (vertical split?) and then a split in top and bottom (horizontal split?) of each of the halves. So if you resize one of the panes vertically, it only affects the other pane in the same half of the window, while if you resize horizontally all the panes will be resized. Basically vertical resizing only resizes the inner split, while horizontal resizing resizes the outer split.
It seems Zellij somehow makes the order of the splits irrelevant.
It seems Zellij somehow makes the order of the splits irrelevant.
I think you're right, I was wondering the same thing.
This looks pretty cool, I use tmux extensively, and having a WebAssembly plugin system could be pretty cool!
What TERM does it support?
In my experience, true color support, Unicode width and RTL language are very problematic.
In my experience, true color support, Unicode width and RTL language are very problematic.
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.
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.
Has anyone used this with Alacritty? Seems like they would be a good match.
Looks cool.
I wonder how it handles the clipboard ? with Wayland ?
I would love to see a small screen ready made option mode that uses tabs as default instead of panes because panes don't make much sense on a small screen.
Do you plan on supporting mouse shortcuts? I currently use byobu, and it's useful to start scrollback mode on mousewheel up
The latest version from cargo does not build for me.
edit: After running "rustup update" it does install. I am liking Zellij so far.
edit: After running "rustup update" it does install. I am liking Zellij so far.
It's the typical Rust problem and my biggest gripe with the Rust ecosystem: many libraries are using unstable/nightly features, making development needlessly frustrating for people using the stable Rust release.
Rust devs, please don't. Not every Rust developer uses rustup or knows how to solve this issue, not everyone is willing or able to use the nightly build just so dependency 21/63 doesn't throw errors.
Rust devs, please don't. Not every Rust developer uses rustup or knows how to solve this issue, not everyone is willing or able to use the nightly build just so dependency 21/63 doesn't throw errors.
It doesn’t appear that this uses any nightly or unstable features. The parent didn’t say why this doesn’t compile, it’s probably something else. Maybe they have an older rustc.
Nice suggestion. I had not updated my rust installation in a couple of months.
After doing rustup update now it installs correctly. Thank you.
After doing rustup update now it installs correctly. Thank you.
Is there any way to disable the use of Powerline fonts? Vim-airline does it well, why not this new project?
What terminal does it support?
Historically, different terminal color, Unicode font wide
How do I tell Zellij to passthru Ctrl+ArrowKeys ?
Looks like a cool Byobu alternative.
how does it differs from iTerm2?
A better comparison would be tmux. iTerm2 is a terminal emulator, where tmux is a multiplexer.
Totally different tools. You could run this inside of Iterm
You have a problem and you need a configuration language, so you pick YAML. Now you have two problems.
Take a leaf out of Rust's book and use something simple and sane like TOML, YAML is a mess.
See: https://github.com/cblp/yaml-sucks
Otherwise this looks like a great project, please don't ruin it with YAML.
Take a leaf out of Rust's book and use something simple and sane like TOML, YAML is a mess.
See: https://github.com/cblp/yaml-sucks
Otherwise this looks like a great project, please don't ruin it with YAML.
YAML sucks but so does TOML, especially when it comes to nested data structures like the layout.yaml shown on the front page.
There are no good configuration languages in existence and there never will be. We have rejected Lisp/sexp so now we must suffer endlessly.
There are no good configuration languages in existence and there never will be. We have rejected Lisp/sexp so now we must suffer endlessly.
I think JSON would be perfect if it a) allowed comments, and b) had multi-line strings.
It has exactly five data types, each with very clear and distinct notation that nests consistently (the top level isn't somehow "special" and there's no messing with significant whitespace). Only two collection types: keyed, and unkeyed. In some sense it feels like the apotheosis of untyped data-modeling.
It has exactly five data types, each with very clear and distinct notation that nests consistently (the top level isn't somehow "special" and there's no messing with significant whitespace). Only two collection types: keyed, and unkeyed. In some sense it feels like the apotheosis of untyped data-modeling.
I just wish JSON had fixed decimal numbers, a timestamp type, and a binary blob type :/
[deleted]
a) reminds me so much of this classic
https://thedailywtf.com/articles/the-inner-json-effect
“Tell us what you did to JDSL,” one of the VP’s asked.
“I don’t think I did anything,” Jake answered. “I’ve only been here two weeks, trying to learn JDSL and how the customer portal works. I don’t even know how to deploy it!”
“You made a few commits to Subversion!” Tom shouted.
“Well, yes. I added a few code comments, trying to–”
“You can’t use comments in JDSL!” Tom shouted. “THAT’S WHAT BROKE IT!!”
https://thedailywtf.com/articles/the-inner-json-effect
“Tell us what you did to JDSL,” one of the VP’s asked.
“I don’t think I did anything,” Jake answered. “I’ve only been here two weeks, trying to learn JDSL and how the customer portal works. I don’t even know how to deploy it!”
“You made a few commits to Subversion!” Tom shouted.
“Well, yes. I added a few code comments, trying to–”
“You can’t use comments in JDSL!” Tom shouted. “THAT’S WHAT BROKE IT!!”
That 100% has to be fake. I NEED it to be fake. Are there production systems that work like this? Du they have one "rockstar" developer who does stuff like this?
Most of TDWTF is a kernel of truth surrounded by about three pages of fiction.
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.
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.
Have you looked at Cuelang [1] as a configuration language or source of truth?. It's still new but it's a superset of JSON but attempted to combine data/schema into one and reject inheritance and replace with validation instead.
[1] https://github.com/cuelang/cue/tree/master/doc/tutorial/basi...
[1] https://github.com/cuelang/cue/tree/master/doc/tutorial/basi...
Take a look at HOCON (Human-Optimized Config Object Notation)
https://github.com/lightbend/config/blob/main/HOCON.md
https://github.com/lightbend/config/blob/main/HOCON.md
Yes! I logged in just to mention HOCON, then I noticed you have mentioned it already :- )
So, the project you linked to is Java / Scala: https://github.com/lightbend/config
And there're also (basic? complete?) HOCON parsers in Javascript and Rust — I investigated this a while ago, because I want to use HOCON everywhere in my projects:
https://docs.rs/hocon/0.5.1/hocon/ (Rust)
https://www.google.com/search?q=hocon+javascript (Js, a few different)
The Rust version:
> This implementation goal is to be as permissive as possible, returning a valid document with all errors wrapped in `Hocon::BadValue` when a correct value cannot be computed
How nice :- ) (it seems to me)
So, the project you linked to is Java / Scala: https://github.com/lightbend/config
And there're also (basic? complete?) HOCON parsers in Javascript and Rust — I investigated this a while ago, because I want to use HOCON everywhere in my projects:
https://docs.rs/hocon/0.5.1/hocon/ (Rust)
https://www.google.com/search?q=hocon+javascript (Js, a few different)
The Rust version:
> This implementation goal is to be as permissive as possible, returning a valid document with all errors wrapped in `Hocon::BadValue` when a correct value cannot be computed
How nice :- ) (it seems to me)
I agree about sexps, it feels like the right default for storing human readable data. The only place where I think it's a little weak is when used more like markup, since data would need to be in quoted strings.
That definitely seems like a solvable problem though.
That definitely seems like a solvable problem though.
Or, to avoid sooner or later falling into Greenspun's Tenth Rule, just go immediately to Lua, which actually evolved out of a configuration language (https://www.lua.org/history.html), so it has syntax & features that are quite friendly for writing configs.
I'd never heard of Greenspun's tenth but that's good to know! I had a personal theory that all program configuration interfaces eventually become programming languages (poorly) and maybe this fits in there.
> I had a personal theory that all program configuration interfaces eventually become programming languages (poorly) and maybe this fits in there.
This is absolutely true. Another recent high profile example I can think of is HCL with terraform.
This is absolutely true. Another recent high profile example I can think of is HCL with terraform.
I actually just stumbled upon an article where someone went through HCL and finally landed at Lua: http://dnaeon.github.io/choosing-lua-as-the-ddl-and-config-l...
Lua tables are great for nested configurations like layouts.
> It's fashionable to hate XML because it was used in a lot of places it was a bad fit in the 00s, but at least it's a pretty good document language.
> YAML though is always a bad fit. If you want machine readable config, use JSON; human readable, use TOML. When does YAML ever fit?
https://twitter.com/carlmjohnson/status/1372224080749993988
> YAML though is always a bad fit. If you want machine readable config, use JSON; human readable, use TOML. When does YAML ever fit?
https://twitter.com/carlmjohnson/status/1372224080749993988
The human readable part is a bit subjective. I find YAML more human readable than TOML.
Readable, maybe? I mean as long as the YAML is correctly quoted, sure, it looks fine. But that's a big if. But writeable, hell no. I have been writing YAML for years and still have no idea how the quoting works, and not for lacking of looking it up in the past.
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'd very much rather recommend HJSON [1] than TOML.
[1]: https://hjson.github.io/faq.html
If replacing JSON is the objective, I'd very much rather recommend HJSON [1] than TOML.
[1]: https://hjson.github.io/faq.html
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.
But there is also JSON5, among the most popular alternatives. Then HOCON you mention, and probably a myriad more.
> it doesn't really support nested data like JSON would
This is just plain wrong. It supports exactly the same kind of nesting as JSON.
This is just plain wrong. It supports exactly the same kind of nesting as JSON.
Could your problem be partially resolved by having a key called description or comments where you could provide some clarification?
But now that's part of the data and the parser doesn't know any better. Comments are more useful if they are close to the thing being talked about.
Configuration language seems to be a hot topic at HN today, as every day. "Don't use X, use Y instead" has spawned this thread with everybody putting in their favorite configuration language in the hat for consideration. Lets list the ones that have appeared so far:
YAML, TOML, Lisp, Dhall, JSON, EDN, JSON5, HOCON, Lua, HCL, XML, HJSON, Starlark, strict yaml
About a third of which I'd never heard of. And because I can't help myself (the dogpile is so enticing!), I have to say that the one that I'm most interested in is: Dhall.
YAML, TOML, Lisp, Dhall, JSON, EDN, JSON5, HOCON, Lua, HCL, XML, HJSON, Starlark, strict yaml
About a third of which I'd never heard of. And because I can't help myself (the dogpile is so enticing!), I have to say that the one that I'm most interested in is: Dhall.
You can find absurd behavior during corner cases in nearly any non-trivial language. YAML is a great language when you need to represent objects in something universal and human readable/writable. Not perfect of course, but TOML's limitations can turn stuff into a monstrosity with it's limitations. Ansible inventory files come to mind here.
One can find absurd behavior in corner cases of any non-trivial language, but one can find absurd behavior in YAML without even looking for it.
Such as? All these cases with no and norwegian or whatever but I haven't run into major problems and use it frequently.
e: And, AFAIK, I believe the latest YAML 1.2 spec (from 2009) has addressed these issues.
e: And, AFAIK, I believe the latest YAML 1.2 spec (from 2009) has addressed these issues.
The "no"/"norwegian" thing is emblematic of very sloppy thinking in YAML's design, and it's far from the only example.
It's possible to avoid these pitfalls - like people do with PHP - but why burden users with that in a new project when better options have been available for years?
They obviously like Rust, why not just follow their lead with TOML?
It's possible to avoid these pitfalls - like people do with PHP - but why burden users with that in a new project when better options have been available for years?
They obviously like Rust, why not just follow their lead with TOML?
That "feature" regarding "no" hasn't even been present in the YAML spec since 2009.
Thanks for being clear about this and repeating it. I didn’t know. I think I will only use YAML 1.2 as configuration language.
I use it frequently too, but there's some terrible edge cases: https://stackoverflow.com/questions/53648244/specifying-the-...
? I don't think these are issues with Yaml 1.2, the spec since 2009.
What about `thing: 1.0` and `thing: 1.0.0`?
Parser implementations have also been buggy. The ruby one in particular being a source of RCE's. Of course, these are implementation issues, but surely a simpler specofication would be easier to implement. And the current specification is anything but simple, clocking 84 pages in the PDF flavour.
Parser implementations have also been buggy. The ruby one in particular being a source of RCE's. Of course, these are implementation issues, but surely a simpler specofication would be easier to implement. And the current specification is anything but simple, clocking 84 pages in the PDF flavour.
The NO alone should give you pause...
It's a language that coerces basic strings...
It's a language that coerces basic strings...
I think the biggest problem with YAML is not YAML itself but what people use it for. It's very flexible and readable for smaller files (much more than TOML - which is awful for hierarchical data).
A bigger problem is that so many things are using config files that should be proper DSLs or libraries, but no one wants to maintain a library (or create RCE as a service by accident) and no one wants to write a parser/interpreter.
Most of the "YAML sucks" issues would go away if we stopped treating LowCode as something desirable (we do actually need to write code sometimes, as it happens) and if we had better sandboxing/parser generators along with less animosity towards DSLs.
A bigger problem is that so many things are using config files that should be proper DSLs or libraries, but no one wants to maintain a library (or create RCE as a service by accident) and no one wants to write a parser/interpreter.
Most of the "YAML sucks" issues would go away if we stopped treating LowCode as something desirable (we do actually need to write code sometimes, as it happens) and if we had better sandboxing/parser generators along with less animosity towards DSLs.
There is now a good parser/interpreter already written for a proper configuration DSL in Rust - https://github.com/facebookexperimental/starlark-rust
My beef with YAML is that configuration should be flat, not hierarchical. There should be at very most one layer of nesting, to facilitate categories. INI files are fine.
People do unholy things with it like nest bash scripts in it that should never be done. Text files should never have more than one syntax needing parsing. It's bad enough, say, embedding SQL into some python. But doing that with YAML is just the worst.
You should be able to use regexes to deal with non-code text files. JSON, YAML, the whole motley crew require parsing. Don't get me started on JSON log files.
People do unholy things with it like nest bash scripts in it that should never be done. Text files should never have more than one syntax needing parsing. It's bad enough, say, embedding SQL into some python. But doing that with YAML is just the worst.
You should be able to use regexes to deal with non-code text files. JSON, YAML, the whole motley crew require parsing. Don't get me started on JSON log files.
This feels like a bit of a bikeshed. There are problems with many configuration languages. I don't see anything related to yaml on their issue tracker.
HN on ShowHN posts is almost always a series of bikesheds
> bikeshedding
> Futile investment of time and energy in discussion of marginal technical issues
I don't see how the choice of configuration file format is a marginal technical issue. It makes a big difference to the ergonomics of a tool.
It's one of the things I like most about Rust over my main programming language Kotlin. Rust has Cargo which uses TOML, which is nice and simple. It's so much more pleasant to use than Koltin's Gradle.
> Futile investment of time and energy in discussion of marginal technical issues
I don't see how the choice of configuration file format is a marginal technical issue. It makes a big difference to the ergonomics of a tool.
It's one of the things I like most about Rust over my main programming language Kotlin. Rust has Cargo which uses TOML, which is nice and simple. It's so much more pleasant to use than Koltin's Gradle.
If your Rust program needs a more complicated configuration (conditionals, access to APIs and so on), also look at Facebook's Starlark parser and tooling[1]. Starlark is a subset of Python used by Bazel, Buck and a few other projects.
[1]: https://github.com/facebookexperimental/starlark-rust
[1]: https://github.com/facebookexperimental/starlark-rust
Non-rhetorical questions: why not use the language itself so people can leverage features like autocomplete, type-checking, linting, and intuitive error handling in an IDE? Is there anything about Rust that makes it impractical for representing config/dependencies/etc?
how do you imagine this working? should the binaries for this ship a rust compiler?
You could, for example, compile AOT to a JSON file and build everything deterministically from there. Tell devs to not edit that JSON directly. I believe NPM and Yarn do something similar.
i have no idea what you're saying
>compile AOT to a JSON file and build everything deterministically from there
you want the dev that develops zellij to AOT compile all settings (that they set using rust as you imagine) to a JSON file that is then... what by end users? inspected but not edited? how would settings change then?
>compile AOT to a JSON file and build everything deterministically from there
you want the dev that develops zellij to AOT compile all settings (that they set using rust as you imagine) to a JSON file that is then... what by end users? inspected but not edited? how would settings change then?
Yep. Rust is a compiled language with monomorphized generics. It's slow to compile, and also you'll need to carry rustc everywhere. rustc is huge.
Or, one could embed Chez Scheme, the compiler of which is like 800 kB in size and compiles stuff very quickly.
Or, one could embed Lua, which has simple syntax and built for that exact purpose
Possibly, but the dilemma of having to choose between Lua 5.4, with its portability and language features, and LuaJIT's performance isn't very pleasant. I'm sure that LuaJIT updated to 5.4 version language would be very popular, but it doesn't exist right now.
That is one thing people love about xmonad, you write your config in haskell.
Another option is JSON with the "$schema": "..." item[0]. Most editors seem to pick that up automatically and provide autocomplete and type-checking.
[0] https://json-schema.org/
[0] https://json-schema.org/
The point of config/scripting languages is to make the user's life easier. I assume nobody wants to deal with the Rust borrow checker and lifetime annotations while tinkering with their configuration. So it depends - should it be an unchanging set of options/flags the user can switch around and then recompile? Probably fine though it'll never be as quick as e.g. recompiling programs from the suckless project. Want to expose interfaces for users to expand and modify the program's code? Not so much.
Rust is a fantastic language, but it's probably not the kind of language you want for this purpose. Same reason why game engines often have scripting languages; so people don't have to deal with C++ where it's not required for performance.
Imho the best compromise is embedding something like Lua which is simple and still flexible enough to allow more than JSON-style declarations.
Rust is a fantastic language, but it's probably not the kind of language you want for this purpose. Same reason why game engines often have scripting languages; so people don't have to deal with C++ where it's not required for performance.
Imho the best compromise is embedding something like Lua which is simple and still flexible enough to allow more than JSON-style declarations.
YAML is the worst, kill it with fire. Whether TOML is decent alternative is debatable though, i'd prefer EDN.
If you don't like it, just generate the YAML from something else: https://github.com/dbohdan/remarshal
Search up "strict yaml" it is a pretty good alternative to both.
There are a million good alternatives. The question is why would you deliberately choose YAML for a new project when we now have a lot of real world experience about how it sucks. It's like deliberately choosing SOAP for a new API…
I get the yaml hate - I used to do that too. But as I worked more with it I can say I have not had any problems.
I think toml feels actually more complex
I think YAML works fine if you're mapping it into typed data structures, because if you know the target type, you can coerce where possible and fail with an error message otherwise. It can potentially cause a mess if you're using it in a dynamic language, and aren't explicitly coercing/validating the input.
For hierarchical data I've found JSON5 to be much more enjoyable to work with than YAML or TOML.
Yes, TOML is great for some things but not hierarchical data.
> You have a problem and you need a configuration language, so you pick YAML. Now you have two problems.
So much debate could have been avoided if we stuck with S-Expressions from the beginning.
So much debate could have been avoided if we stuck with S-Expressions from the beginning.
One of the most painful things about using tumxp is modifying the YAML to make it useful.
Was hopeful this would leverage TOML as it's built using rust.
Was hopeful this would leverage TOML as it's built using rust.
same comment, different config format, year after year after year...
i submit dhall as a good alternative
https://dhall-lang.org/
https://dhall-lang.org/
YAML is the worst choice. Please use something else!
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 immediately obvious to me what I'd use that for).
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 immediately obvious to me what I'd use that for).
It's people interested in Rust advertising to people interested in Rust. The programming language is as much the point as the program's purpose.
Advertising the language could attract contributors to the project. Especially true for a newish language that is just starting to gain widespread traction.
>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.
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.
It depends whether you've been burned by memory safety/data race CVEs in the past. For better or for worse, some people actively search out software written in Rust specifically because the choice to use C/C++ is not opaque to the user.
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...).
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
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!
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.
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).
> 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 :- ))
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.
If it's more secure, that's harder to measure. But that's not even the tagline, just that it's written in Rust.
I wrote "or are security-dangerous like C" actually,
— that's easy to measure, if it's written in C or not (or some other memory unsafe language)
— that's easy to measure, if it's written in C or not (or some other memory unsafe language)
The implementation matters a good deal more than the programming language.
The programming language is a pretty substantial part of the implementation, though, if not the most substantial one. Rust is qualitatively different than a language like C (in that it is memory safe) or Python (in that it is compiled and fast).
I feel like this stuff should be posted in a Rust-specific site, not on HN.
I think advertising the language is important. Rust is fairly strict which improves stability. It also means that I'm not downloading some bloated electron crap.
marti-oss(1)
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 noticed is that it uses ctrl-r as a core shortcut. Mega problem: ctrl-r is a built-in bash feature which I use every day to recall previous commands. This makes me think I can't use this tool at all.
I would suggest to consider taking a page from tmux's book. Just use a global modifier key. Ctrl-b is what tmux uses, so you know it's safe. Other software being developed knows they should avoid it, because tmux uses it. By also using it, you'd no longer have to dance around the global space of what shortcuts every software in existence is using. Additionally, if you use ctrl-b to enable your commands, you can minimize your interface. Currently you're using two entire lines to display your menu. That's going to become tiring as I use zellij 8 hours a day for years. I'll have to hide it eventually. Instead, what if you reduced it to zero lines? Put "ctrl-b: menu" in the upper right of your title bar. Pressing ctrl-b now enables commands and shows what your next keypress will do. You have now (1) avoided breaking existing shortcuts, (2) aligned with established standards (3) given some familiarity to welcome tmux users (4) expanded visible screen space and (5) simplified your menu system. You can also now remove ctrl-g since the interface is "locked" by default until I want to start interacting with it.
Anyway that's my 2 cents. Thanks for this exciting demo.