Respect CDPATH

[robertmeta]

Is there any reason it does not support CDPATH?

[GarySmith]

Without CDPATH support, zoxide is a step backward from the basic cd command provided in bash. Too bad

[naquad]

zoxide is great and it has streamlined my workflow A LOT.

Although, in the times before it there were named directories, cdpath, and the completion of all this provided by zsh. While named directories are working as expected - no questions here, the cdpath + its completion is something I would highly appreciate as the muscle memory after years of typing still makes it appear faster than I can think about what I'm doing.

Please consider the option to process the cdpath to make zoxide even more awesome and let alias cd=z become a common default on every localhost out there :)

Thank you.

[fawaf]

+1 1000%, was very surprised when i was trying out zoxide that it did not support CDPATH

[DeadlySquad13]

Currently found a workaround using builtin zoxide functions. I have all commonly visited places in ~/.bookmarks which is added in CDPATH. I just added all links into zoxide database from this directory:

zoxide add ~/.bookmarks/*

now all these links are in database as if I have visited them. And it's possible to jump to them using zoxide.

I think t's quite easy to develop a one liner iterating over all directories from CDPATH and adding items inside into database if you have a lot of entries.

It's not automatic, of course, and these directories will be purged from zoxide database over time if you don't enter them. But I think the whole idea of bookmarks is a little bit contradicting zoxide frictionless approach to navigating your filesystem. So I personally decided that this temporary workaround is enough for me and it's better to try to adapt zoxide system: over time all these bookmarks you were manually managing with CDPATH would get into zoxide anyway. And with proper priorities!

Anyway, from a project design view, it's bad when users get surprised: after all, it's quite strange that "smarted cd command" doesn't have some functionality of a cd. It would be so cool if zoxide would respect CDPATH so that users wouldn't need to change their workflow when making first steps in adapting zoxide. Anyway, thanks for your hard work making this cool project!

[beorn]

A bit annoying for sure, but the workaround described above:

function add_cdpath_to_zoxide() {
  local pths = ()
  for pth in $cdpath ; do
    [[ -d "$pth" ]] && pths += ("${pth}"/*(/N))
  done
  if [[ ${#pths[@]} -gt 0 ]]; then
    zoxide add "${pths[@]}"
  fi
}

c=~/Code # example zsh named directory
cdpath=( ~c/*(/) ~/Desktop/*(/) ~/Documents/*(/) )

if (( $+commands[zoxide] )) ; then
  eval "$(zoxide init zsh)"
  add_cdpath_to_zoxide
fi

[wolf]

This seems pretty easy to fix for real (I mean: I would write code to fix this and submit a PR). But I have questions:

• Is fixing this something @ajeetdsouza wants? Or is the work-around above the final answer?
• If a fix is desirable, the big choice is: examine $CDPATH separately? Or add those places you would get to through $CDPATH to the database? If the latter, the code must keep the database up-to-date as things appear underneath $CDPATH or as $CDPATH itself changes. That choice is easy searching, but much more maintenance. My feeling is to keep them separate.
• If they were separate, which should be searched first? Or maybe if a name is reachable through $CDPATH that actually just throws it into the competition with names already in the database (and if that name was already in the database, then that's all the information we need) ... and of course, once such a name "wins", then it's in the database and later choices are easier.

Thoughts? Is this something worth spending my time on?