Keymap actions to cd into a history entry's directory

Ideas
1

I often find a command in the search and really want its directory, not the command itself: the repo I built something in, or the folder I edited a config in. switch-context filters the list to that context, but it doesn’t take the shell there.

This was asked for in #1450 (the “cd to the path where the command was run” part). #1494 shows a zsh/fzf plugin built around the same need.

I’d like to propose two keymap actions:

  • accept-cd: close the search and run cd to the selected entry’s directory.
  • return-cd: put that cd on the command line instead, like return-selection.

No default binding; users bind them, e.g. [keymap.prefix] "g" = "accept-cd". They also work from the inspector.

The path would be quoted for each shell the integration supports (bash/zsh/fish, nushell, xonsh, PowerShell). Entries without a usable directory (imported history records unknown) would close the search like return-original.

I have a working implementation, tested with bash, zsh and fish (the shells CI runs) and with nushell, xonsh and pwsh locally. I’d be happy to open a PR if this sounds useful.

2 Likes
2

This sounds super useful to me, thank you for suggesting! please do open a PR.

Also would not be opposed to have it bound to a prefix binding by default? maybe prefix-g

(it would also be great if you could link this thread from the PR!)

3

Thanks! Here’s the PR: feat(search): add accept-cd and return-cd keymap actions by babs · Pull Request #4319 · atuinsh/atuin · GitHub

Prefix g runs accept-cd like you suggested, and return-cd is on prefix G as it
was also free and seemed coherent.

Testing on PowerShell turned up a separate bug. On Linux and macOS the history
kept the directory the shell started in, so the cd would land in the wrong
place. I opened a fix for it in fix(powershell): record the current directory instead of the launch one by babs · Pull Request #4318 · atuinsh/atuin · GitHub

1 Like