zsh’s autocomplete scrolls through only those previously used commands that match what has been typed so far. So I typically enter cd ./s and then the up arrow takes me through my most recently visited project folders, ./src/project_1, ./src/project_2…
Even better, it works on any command, not just cd.
History prefix search is a useful feature, but it can’t fully replace tools like z and zoxide. Say your two most recent projects are ~/projects/src/rails/ and ~/projects/src/lobsters/. If you want to jump to lobsters from within ~/projects/, you can type z lob or potentially even z l, both of which are faster to type than cd ./s<up><up>.
What’s more, you can always use the same z lob and z rails to jump to those folders from anywhere, whereas the cd command would have to be adjusted if you were within ~ or within rails/. The cd command also requires a different amount of <up> presses depending on which folder you visited most recently, while the z commands can be done from muscle memory.
This usually does not work if your current directory is not the same as the one when you typed the command, except you use absolute paths. Or maybe I misunderstand what you exactly do.
Anyway, try it out, I wouldn’t want to miss this kind of instant directory change. Usually, it only takes 4 key presses ‘z [space] [two letters of target dir name]’ and you’re in the target dir - no need to reach for arrow keys or ctrl.
So, yes, it does solve a problem that does exists. Maybe it’s not a problem for you. Or maybe you don’t know yet you have that problem, but will once you tried out this (or z, or autojump, or any of the other solutions – I reckon the fact that there are so many alternative implementations should be a pretty good indicator that a non-trivial amount of people think this is a problem…).
It mentions it’s inspired by z and z.lua. There’s also jump or autojump, or twenty more if you search a bit. “It’s in Rust” is the big helper here, I suppose. Jumping to directories is never something I’ve found noticably slow even with z, but there’s always an audience trying to eek out the best performance.
zoxide’s README says it’s mainly trying to speed up displaying the prompt, as opposed to speeding up the actual jumping. All z-like tools delay the prompt a bit because they run code to track the current directory before each prompt.
Ahh, that makes more sense! I used to run some pre-prompt display stuff to get git statuses added into my prompt and that definitely slowed things down. Now I just run a ‘git status’ when I actually want that info and things are snappier. Every little bit adds up on those things.
I’ve been working on and off on a client/server version of this, with a persistent daemon process taking care of the database. I feel that would be a better design, as the work performed by the client after each key press would be really minimal. That daemon could also eventually be used for automating other parts of the CLI experience.
I did consider this, but I didn’t want an entire process running on my computer for the sole purpose of serving me cd suggestions. Moreover, given how fast zoxide already is, I doubt that a client-server model would be a massive improvement.
You’re right, I’m sure it’s fast enough. The main point would be to add more features in addition to jumping: a central daemon that talks to all your shells simultaneously could certainly help for many other things.
Yeah, I’ve thought about this as well. Just couldn’t be bothered to figure out all the possible security implications, and never wanted it bad enough. But it could be the sort of generic project that opens up a lot of possibilities we don’t even see yet… Also, who doesn’t love over-engineering stuff ? :-)
Right now I was thinking client/server on the same machine, using a UNIX socket for communication, so the security implications aren’t big. But maybe you’re right, and we could imagine a cloud-based version!
I’ll try to ping you if I ever put something on GitHub :)
Yeah, please do. I shudder to think what the reaction of some folks on HN or here or reddit would be if you announce ‘I made a client-server version of cd’! :-)
I do basically the same thing but in pure shell:
But it’s not written in rust, so that’s a major drawback!
Is this solving a problem that doesn’t exist?
zsh’s autocomplete scrolls through only those previously used commands that match what has been typed so far. So I typically entercd ./sand then the up arrow takes me through my most recently visited project folders,./src/project_1,./src/project_2…Even better, it works on any command, not just
cd.History prefix search is a useful feature, but it can’t fully replace tools like z and zoxide. Say your two most recent projects are
~/projects/src/rails/and~/projects/src/lobsters/. If you want to jump tolobstersfrom within~/projects/, you can typez lobor potentially evenz l, both of which are faster to type thancd ./s<up><up>.What’s more, you can always use the same
z lobandz railsto jump to those folders from anywhere, whereas thecdcommand would have to be adjusted if you were within~or withinrails/. Thecdcommand also requires a different amount of<up>presses depending on which folder you visited most recently, while thezcommands can be done from muscle memory.This usually does not work if your current directory is not the same as the one when you typed the command, except you use absolute paths. Or maybe I misunderstand what you exactly do.
Anyway, try it out, I wouldn’t want to miss this kind of instant directory change. Usually, it only takes 4 key presses ‘z [space] [two letters of target dir name]’ and you’re in the target dir - no need to reach for arrow keys or ctrl.
So, yes, it does solve a problem that does exists. Maybe it’s not a problem for you. Or maybe you don’t know yet you have that problem, but will once you tried out this (or z, or autojump, or any of the other solutions – I reckon the fact that there are so many alternative implementations should be a pretty good indicator that a non-trivial amount of people think this is a problem…).
It mentions it’s inspired by z and z.lua. There’s also jump or autojump, or twenty more if you search a bit. “It’s in Rust” is the big helper here, I suppose. Jumping to directories is never something I’ve found noticably slow even with z, but there’s always an audience trying to eek out the best performance.
zoxide’s README says it’s mainly trying to speed up displaying the prompt, as opposed to speeding up the actual jumping. All z-like tools delay the prompt a bit because they run code to track the current directory before each prompt.
Ahh, that makes more sense! I used to run some pre-prompt display stuff to get git statuses added into my prompt and that definitely slowed things down. Now I just run a ‘git status’ when I actually want that info and things are snappier. Every little bit adds up on those things.
If you’d still like to do that (and use zsh), check out powerlevel10k. You can have your cake and eat it too…
I think there are copy-and-paste errors in the instructions for installing via antigen and zplug.
You’re right, I fixed it now. In my defence, it was late at night and I was half asleep!
I’ve been working on and off on a client/server version of this, with a persistent daemon process taking care of the database. I feel that would be a better design, as the work performed by the client after each key press would be really minimal. That daemon could also eventually be used for automating other parts of the CLI experience.
I did consider this, but I didn’t want an entire process running on my computer for the sole purpose of serving me
cdsuggestions. Moreover, given how fastzoxidealready is, I doubt that a client-server model would be a massive improvement.You’re right, I’m sure it’s fast enough. The main point would be to add more features in addition to jumping: a central daemon that talks to all your shells simultaneously could certainly help for many other things.
Yeah, I’ve thought about this as well. Just couldn’t be bothered to figure out all the possible security implications, and never wanted it bad enough. But it could be the sort of generic project that opens up a lot of possibilities we don’t even see yet… Also, who doesn’t love over-engineering stuff ? :-)
Right now I was thinking client/server on the same machine, using a UNIX socket for communication, so the security implications aren’t big. But maybe you’re right, and we could imagine a cloud-based version!
I’ll try to ping you if I ever put something on GitHub :)
Yeah, please do. I shudder to think what the reaction of some folks on HN or here or reddit would be if you announce ‘I made a client-server version of
cd’! :-)Lol, I’m old enough not to care anymore :)