nvim-telescope / telescope.nvim

Find, Filter, Preview, Pick. All lua, all the time.
MIT License
14.82k stars 810 forks source link

Move telescope_history to `stdpath('state')` #2745

Open yochem opened 8 months ago

yochem commented 8 months ago

Is your feature request related to a problem? Please describe. stdpath('data') seems the wrong directory for history files. The base directory sepc introduced $XDG_STATE_HOME for this, and it is adopted by NeoVim (stdpath('state')). It's intention is the following:

The $XDG_STATE_HOME contains state data that should persist between (application) restarts, but that is not important or portable enough to the user that it should be stored in $XDG_DATA_HOME. It may contain:

actions history (logs, history, recently used files, …)

current state of the application that can be reused on a restart (view, layout, open files, undo history, …)

https://specifications.freedesktop.org/basedir-spec/latest/ar01s03.html

As stated above, this includes history files.

Describe the solution you'd like Change the default path from stdpath('data') .. '/telescope_history' to stdpath('state') .. '/telescope_history'.

Describe alternatives you've considered Of course just keeping it like this.

Additional context It is of course not as easy as just substituting stdpath('data') with stdpath('state'). That would introduce the following problems:

  1. Users lose their previous history upon updating
  2. stdpath('data')/telescope_history would keep existing even though it is not used anymore
  3. IF users would sync their telescope_history (...why?), they would have to update the location

Possible solution: Have a function that checks if stdpath('data')/telescope_history exists. If so, move file to new location. Most users won't notice it, users that sync their telescope history will notice and have to update (with a simple git add $XDG_STATE_HOME/nvim/telescope_history, assuming they use Git).

To cover even more: if both exist, prepend the data history to the state history file. Prepending because its content is probably older than the state history content.

Let me know if you're alright with this change. I can implement it and create a PR.

jamestrew commented 8 months ago

I'm inclined to agree with you but... not sure if most people care 🙃

If we were to do this, I think just going to breaking change route is the way to go. Just rip the bandaid off quickly. It shouldn't affect most people anyways I think.

I'll let others chime in though before we make a decision.

yochem commented 8 months ago

I'm inclined to agree with you but... not sure if most people care 🙃

I agree that most people probably don't care, but when a standard is adopted, it feels like the right thing to 100% comply to it.

If we were to do this, I think just going to breaking change route is the way to go. Just rip the bandaid off quickly. It shouldn't affect most people anyways I think.

Good point. Let's hear what the others have to say indeed.

Conni2461 commented 8 months ago

I do not care about this at all. Generally speaking i would say this option can already be configured, so why would we care about creating "noice" for our users (because honestly speaking moving a history file for "no" good reason could be considered noice, as we have announce it as breaking change).

Also i hate the idea of shipping a migration tool (on startup function) that automatically does this for us, it just unnecessary code, that might be buggy, if a user has already configured something else, also regards to windows, etc.

But i am not against doing that if we already do some kinda breaking change regarding history, aka saying history v1 is now, dead, we now offer a new history v2 with more features. no backwards compatibility. you lose it regardless of this change. aka implementing https://github.com/nvim-telescope/telescope.nvim/issues/2290

Does that make sense?

tummetott commented 7 months ago

I completely agree that relocating this file to stdpath('state') makes sense. I also support the idea of making this move without a migration tool; a straightforward move, accompanied by documentation. Users who are particular about their history can then manually transfer the file.

It has been bothering me for some time that this file is currently situated in the incorrect XDG directory.