State is lost on reboot by default when ~/.cache is a tmpfs
bew opened this issue · 11 comments
Env: OSTYPE=linux-gnu CPUTYPE=x86_64 MACHINE_TYPE=x86_64 ZSH_VERSION=5.8.1
a rapid check of the code seems to show that I could set the FAST_WORK_DIR
to change where the state of FSH is stored, by trying that:
FAST_WORK_DIR=~/.long_term_cache/zsh--fast-syntax-highlighting
echo "FAST_WORK_DIR (before zi): $FAST_WORK_DIR"
zi light z-shell/F-Sy-H
echo "FAST_WORK_DIR (after zi): $FAST_WORK_DIR"
Starting a new shell I get:
FAST_WORK_DIR (before zi): /home/lesell_b/.long_term_cache/zsh--fast-syntax-highlighting
FAST_WORK_DIR (after zi): /home/lesell_b/.cache/fsh
Which seems wrong...
In addition to that, it seems that the chroma system assumes the theme is stored in ~/.cache/fsh, and does not check what FAST_WORK_DIR
is set to.
I tried to fix that in #24, but further testing showed the weird inconsistency above.
Repro steps:
$ mkdir -p /tmp/test-home/{.cache,.long_term_cache}
$ vim /tmp/test-home/.zshrc
... (see below)
$ git clone https://github.com/z-shell/zi.git /tmp/test-home/zi-repo
...
$ HOME=/tmp/test-home zsh
# in nested shell
$ fast-theme free
$ cd; tree .cache .long_term_cache
.cache
└── fsh/
├── current_theme.zsh
├── current_theme.zsh.zwc
├── secondary_theme.zsh
└── secondary_theme.zsh.zwc
.long_term_cache
1 directory, 4 files
Where /tmp/test-home/.zshrc
is:
source ~/zi-repo/zi.zsh
FAST_WORK_DIR=~/.long_term_cache/zsh--fast-syntax-highlighting
echo "FAST_WORK_DIR (before zi): $FAST_WORK_DIR"
zi light z-shell/F-Sy-H
echo "FAST_WORK_DIR (after zi): $FAST_WORK_DIR"
And I get:
FAST_WORK_DIR (before zi): /tmp/test-home/.long_term_cache/zsh--fast-syntax-highlighting
FAST_WORK_DIR (after zi): /tmp/test-home/.cache/fsh
So my main question is:
How to store the state of FSH outside of ~/.cache without changing $XDG_CACHE_HOME
?
Is changing FAST_WORK_DIR
the correct way ? (in which case the inconsistency above should be solved)
Thanks, will get back to this after triage.
For faster communications and keeping track of @z-shell - z-shell.slack.com/shared_invite
Actually this behavior seems intended:
Lines 59 to 62 in a9b3e37
Making it default to ~/.cache when the given directory is not writable.
I'm not sure it's a good idea, maybe the plugin could move its state directory to ~/.local/<some-directory>
?
NOTE: as a workaround I'll just make sure the directory is created if it doesn't exist
I am thinking about setting a global variable for cache:
https://github.com/z-shell/zi/blob/82b6a194ca89f61765fc90456513d11ce6844788/zi.zsh#L58-L67
Which then can be adjusted for all plugins:
https://z.digitalclouds.dev/docs/guides/customization#-customizing-paths
I'd argue though that what F-Sy-H puts in the cache dir is NOT just cache data that can be lost and not change anything for the user.
It's ACTUALLY storing state / config in a cache directory, which I think is a bad idea.
Usually cache directories should be able to be emptied without impacting the config of the user.
Have you though about having the distinction (like XDG* spec) between cache / config / data / state ?
$XDG_CACHE_HOME defines the base directory relative to which user-specific non-essential data files should be stored.
$XDG_DATA_HOME defines the base directory relative to which user-specific data files should be stored.
$XDG_CONFIG_HOME defines the base directory relative to which user-specific configuration files should be stored.
$XDG_STATE_HOME defines the base directory relative to which user-specific state files should be stored.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, …)
I'd argue though that what F-Sy-H puts in the cache dir is NOT just cache data that can be lost and not change anything for the user. It's ACTUALLY storing state / config in a cache directory, which I think is a bad idea. Usually cache directories should be able to be emptied without impacting the config of the user.
Have you though about having the distinction (like XDG* spec) between cache / config / data / state ?
$XDG_CACHE_HOME defines the base directory relative to which user-specific non-essential data files should be stored.
$XDG_DATA_HOME defines the base directory relative to which user-specific data files should be stored.
$XDG_CONFIG_HOME defines the base directory relative to which user-specific configuration files should be stored.
$XDG_STATE_HOME defines the base directory relative to which user-specific state files should be stored.
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, …)
I will check this properly and let you know about what we can do
I'd argue though that what F-Sy-H puts in the cache dir is NOT just cache data that can be lost and not change anything for the user. It's ACTUALLY storing state / config in a cache directory, which I think is a bad idea. Usually cache directories should be able to be emptied without impacting the config of the user.
Have you though about having the distinction (like XDG* spec) between cache / config / data / state ?
$XDG_CACHE_HOME defines the base directory relative to which user-specific non-essential data files should be stored.
$XDG_DATA_HOME defines the base directory relative to which user-specific data files should be stored.
$XDG_CONFIG_HOME defines the base directory relative to which user-specific configuration files should be stored.
$XDG_STATE_HOME defines the base directory relative to which user-specific state files should be stored.
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, …)
Maybe you have tried this?
P.S. I have started the $XDG
implementation. However, it will take time as the previous maintainer wrote very bad code logic and made it almost impossible to contribute. So started to MAP all repositories under @z-shell, it will bring huge results, but will take some time. ⏲️