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.
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.
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.
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
I just reinstalled completely, by deleting the folder: ~/.local/share/atuin
then run `atuin import`.Downgrade your atuin server to 18.12.1 and run the sync setup on your client(s): https://docs.atuin.sh/cli/guide/sync/
Losing some of the scrollback was a minor nuisance that I kind of lived with until now.
> 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).
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 :)
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.
This is great, but does it mean we'll need to log in somehow? It doesn't seem reasonable to expect the project maintainers to pay for the tokens.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.
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.
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?
- 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.
I'm overall fairly disappointed by this announcement. This IMHO doesn't bode well
Excited to use atuin ai though, especially as it gets more features.
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.
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!