`cd` completes from FileGenerator, which reads one directory: the one you
are standing in. So `cd proj` only ever resolves when proj happens to be
a child of the current directory, and returns nothing at all otherwise --
including for directories visited constantly. That is the opposite of
what cd is normally reached for, and it reads as completion being broken
rather than as a scope limit.
zoxide.extend-cd routes `cd` through the generator `z` already uses, so
local children are offered first and zoxide's frecency database fills in
everything else, reachable by name from anywhere.
Off by default: it shells out to zoxide, and offering absolute paths from
outside the current directory is a real change in what `cd` proposes.
The query is also cached for two seconds. Generators run on every
keystroke and `zoxide query -l` is a subprocess costing ~11ms here, which
is the whole redraw budget; the list only changes when the user changes
directory, so the window costs nothing. This applies to `z` and `zi` too,
which were paying it per keystroke already.
- I think it would be better if one for commands only, one for the spec
handling core logic so people won't be confused by the core logic inside
the commands folder (cleaner I guess)
- Regen docs
thejoker.msk
Kenny B
VERSE
verse91