This is wrong. The standard explicitly tell us "undo" and "view" should go to the STATE:
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, …)
Originally posted by @bam80 in 4f04efb
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
Also here: #19421 (comment)
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
I do not agree as mentioned before.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
if users intentionally create custom view files, those are meant to be reused later. That is a strong argument for keeping them in DATA rather than STATE.
That argument maybe might be applied to the view files, but not to "undo" - those are not meant to be created by user explicitly.
Regarding "reusing later", STATE is perfectly fine with this concept:
The $XDG_STATE_HOME contains state data that should persist between (application) restarts
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
That argument maybe might be applied to the view files, but not to "undo" - those are not meant to be created by user explicitly.
Regarding "reusing later", STATE is perfectly fine with this concept:
Of course those are meant to be created by the user explicitly. Why else would he :set undofile?
You like to reference the spec, so here:
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, …)
Yes, those are important and portable enough to be waranted.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()