Thanks for the good idea. I'm going to continue thinking about this one.

I see that there's a proposal to have rupa/z do something like what you suggest.

If rupa/z goes down that path, I will, of course, mimic it -- I like having ZSH-z continue to be a drop-in replacement for it. Let's keep this issue open.

I wonder, does it make sense anymore to wait for rupa/z to make the first move? Clearly, that project isn't going anywhere at this rate, and even the project owner himself admitted he doesn't use zsh (anymore?)

I think @rupa has always been solely a bash user; he was kind enough to rewrite his code so that it would work in zsh as well.

I'm sure I'm not the only person who uses both zsh with ZSH-z and bash with rupa/z, and it's nice to have rupa/z use the same database in bash without any extra configuration. I like the idea of having a tidier home directory (which is what I think XDG primarily aims for), but not at the expense of making the inter-operation of the two tools more complicated.

I'd like to leave this issue open and continue to cogitate about it.

In the meantime, remember that you can always set ZSHZ_DATA (or _Z_DATA, if you're using rupa/z as well) to any file you want.

In the meantime, remember that you can always set ZSHZ_DATA

I did it and it doesn't work. I added in .zshrc string ZSHZ_DATA=$HOME/.config/zsh/.zhist and it continues to use the file .z in home

@eugene-reim Strange -- it works for me. Would you mind posting your whole .zshrc so that I can try to pinpoint what's going wrong? Thanks!

Yep, sure.
zshrc.txt

In line 93, you have

plugins=(z git sudo zsh-autosuggestions zsh-syntax-highlighting)

z is not my plugin -- that's rupa/z, as packaged by Oh-My-Zsh. If you want to use my plugin, you should follow the instructions here -- you'll want to make sure that you install Zsh-z and change that line to

plugins=(zsh-z git sudo zsh-autosuggestions zsh-syntax-highlighting)

Let me know if that works.

Oh, sorry, I really didn't notice. I'll try it now, thanks.

Yeah it works! Thank you so much and happy New Year btw!

@eugene-reim Happy New Year!

Any updates on this?
You still aren't XDG compliant. Allowing $ZSHZ_DATA to be set to a specific place is not XDG compliant. If it's not set, it must be in the directory pointed to by $XDG_STATE_HOME, and if that isn't set, then it should be $HOME/.local/state (the_ original author of this issue wrote XDG_DATA_HOME, though that is certainly not the right place, as that is not meant for state information like histories)

@bavalpey

Thanks for your comments and your pull request.

My original reason for hesitating to change Zsh-z's behavior regarding data file location remains the same: my utility still enjoys total interoperability with the original rupa/z, and I still use rupa/z when I use Bash, with the same default data file: ~/.z. I would be very surprised if there are not other people who take advantage of this out-of-the-box, very intentional compatibility.

If we adopt your solution, we please one group of people who value the home directory tidiness that XDG compliance affords, and we allow them to remove one line from their .zshrc (ZSHZ_DATA=/path/to/datafile). In doing so, we would have to admit that we are inconveniencing people who use rupa/z in Bash: unless @rupa also adopts XDG conventions, they will always have to add at least one line of code to their dotfiles to maintain compatibility.

More importantly, though, changing the code is easy, but a seamless rollout of the new behavior is hard to accomplish. People are going to wonder why deleting ~/.z does not clear their z -l readout, or - worse - they will ask why backing up ~/.z did not back up their current database. I think a lot of people would appreciate that I try to avoid making breaking changes like that.

I would like to keep this issue open, because I value the aims of the XDG specification. But I am even more interested in continuing to give my users a smooth and predictable experience.