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 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.
> 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.
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.
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).
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.
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. :)
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).
ctrl-w is a very commonly used key to control vim windows. How do you manage with that? I have my tmux leader key mapped to ctrl-z as we hardly use it these days.
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.
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.
> 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.
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.
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.
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.
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.
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?
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.
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 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.
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.
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.
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 :)
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)
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 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.
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.
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.
> 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 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.
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.
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.
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.
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.
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.
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
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.
> 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.
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.
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.
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.
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 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.
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 :-)
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 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).
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.
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.
Not sure what terminal you're using but I was able to get the separators working fine on Windows Terminal with a powerline font enabled on my WSL profile.
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.
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).
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.
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.
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.
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.
“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?
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.
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:
> 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
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.
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 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.
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.
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.
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:
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.
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?
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.
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.
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.
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.
> 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.
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?
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.
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.
>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?
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.
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.
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).
Advertising the language could attract contributors to the project. Especially true for a newish language that is just starting to gain widespread traction.
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.
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.
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.
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.
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
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 :- ))
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 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.
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.