I love tmux and haven't had a reason to switch for a while, but have heard these new Rust based terminal tooling get really popular.
Zellij can do things like floating windows, contextual keybinding guidance (helps learn everything that can be done), and a more complex layout schema. You can disable all the UI eye-candy and switch to tmux-style bindings too.
It's worth trying out. I use both so that I can still function on systems without it.
I switched away from tmux a year or so ago due to one crash I kept getting, but thinking of going back. Really miss the simplicity.
If you watch some of the screencasts and are not impressed, there is nothing more I can do to pitch the idea. My only complaint is that I feel like I am only ever scratching the surface of what the tool can offer.
We use the latest frontier models, which already do a good job of generating commands using well-known binaries and CLIs. On top of that, we integrate a dataset powered by man pages and command outputs to ensure you get the correct command first.
EDIT: I was unaware of Atuin's 'hub' which does things like sync your shell history across computers. I think they use the same sign-in as they already use for that: https://hub.atuin.sh/register
> On top of that, we integrate a dataset powered by man pages and command outputs to ensure you get the correct command first.
Also makes it sound like they're "providing that dataset", rather than generating that from the users computer. Wouldn't that mean it's potentially a mismatch between various versions of the software available? Not to mention some OSes will have a different version of some software available compared to others, how does it deal with those situations if they're shipping a dataset?
"get the correct command first" and "shipping a [external] dataset" are incompatible.
> By default, Atuin AI knows nothing about your machine, other than the operating system and shell. This is the bare minimum required to generate a decent shell command.
> It will soon be able to ask you for access to more data - such as the current directory path, contents, git status, etc - but you must give permission first. This will happen in a similar way to existing agents, and be configurable to an even finer degree in your config file.
I'm overall fairly disappointed by this announcement. This IMHO doesn't bode well
I didn’t think syncing terminal history would be very useful until I tried it, but now I have a hard time when I don’t have it.
I have its search bound to ^r and use Fish shell’s own search for most things, with cross-machine search a keystroke away.
Regardless of which machine I'm using at any given moment I appreciate having "endless history", and the ability to search/filter it. But despite that I don't think I need to actual sync that.
I'm sure there is value to be had from syncing and making all history unified, but it's never appealed to me particularly.
Why does this happen mostly?
They closed it (which is fine) but there is no offline migrate alternative.
It's a shame, and fair enough, their project, but I don't think my wishes and the projects are very aligned.
I keep half meaning to move back to zsh-histdb (I think that's what it was called) but haven't found an impetus to.
I'll probably check if there's a file based sync option next time I switch machines and decide then.
If it helps, you can copy the history table from one db to another in 3 simple lines of sqlite. I’ve done it myself a few times with zero fuss.
This release actually adds support for nucleo, which matches with the same algorithm as fzf and was a common request
I'm sure I recall some unhappy GitHub issues about the shift away...
And the algorithm isn't the value prop for me, not by a long shot. fzf's customizability takes the cake. And now the overall product is way too big and feature-ful for me. I want simple, unix-y software that clicks together like Lego.
You should be proud of the project's success for sure, it's just not for me!
Care to elaborate? Also, don’t you trust that an author knows what they’re doing with AI in the same way as trusting them with their regular code writing skills?
The question is, was adding "AI" to this product requested by most users, or was it done to tick off a marketing checkbox and capitalize on the hype?
I posted a longer comment upthread, but I’ve been self-hosting and running an old version for over two years now, and haven’t had any recurring problems on those fronts. It’s pretty damn stable software and everything they’ve been doing lately has just been extra features and gloss.
There's also a very weak souled scarcity mentality. It feels like you are working to take umbrage, to come up with outrage. Some users do find these features good and useful. That should be celebrated. Demanding features not be present? That's so condescending.
Besides, VC-funded OSS often prioritizes the needs of its shareholders rather than its users. If you find these features useful, that's great. But there's no reason that they should be universally celebrated. The authors might want to listen to all viewpoints.
These are great developers and they’ve built an incredible tool. I use it a hundred times a day. It is very odd and dogmatic to think that because you saw a commit authored by Claude, whatever skills and qualities let them build something so good are now being thrown out.
Edit: I found one: https://github.com/atuinsh/atuin/pull/3231
Please, tell me where the bad code is in that PR. I see 200 lines of extremely straightforward Rust and 500 lines of tests for it.
You can still keep everything you like about the tool without issue, and to the devs’ credit, the sync server is some of the easiest software to self-host possible.
Excited to use atuin ai though, especially as it gets more features.
Losing some of the scrollback was a minor nuisance that I kind of lived with until now.
I was using: eval "$(atuin init zsh --disable-up-arrow)"
Now need to workaround: eval "$(atuin hex init | sed 's/atuin init zsh/atuin init zsh --disable-up-arrow/')"
Probably should create a issue in tracker to point out that this use-case is currently not supported :)
> The terminal still has a running process. If you close the terminal the process will be killed.
Hopefully there is a workaround for this (I'm using then Ghostty emulator).
https://github.com/atuinsh/atuin/releases/tag/v18.12.1
Personally I'll keep using this version for a while until i find something better.
brew remove atuin
brew tap --force homebrew/core
brew version-install atuin@18.12.1
brew untap homebrew/core
~/.local/share/atuin
Downgrade your atuin server to 18.12.1 and run the sync setup on your client(s): https://docs.atuin.sh/cli/guide/sync/
- case insensitive (e.g. inputting "make" matches ("make install", "vim Makefile")
- works on partial matches (e.g. inputting "ma in" matches ("make install", "cd main")
?
for example, for my second criteria:
> - works on partial matches (e.g. inputting "ma in" matches ("make install", "cd main")
typing "ma in" I would expect "make install" to come before "cd main" to come before (what's currently the very first hit) "cd Binaries/Multimedia".
I'm now reading about https://docs.atuin.sh/cli/configuration/config/?h=fuzzy+daem... while not managing to really get what would seem natural. Sigh.