z-shell/F-Sy-H

State is lost on reboot by default when ~/.cache is a tmpfs

bew opened this issue · 11 comments

bew commented

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.

bew commented

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
bew commented

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)

ss-o commented

Thanks, will get back to this after triage.

For faster communications and keeping track of @z-shell - z-shell.slack.com/shared_invite

bew commented

Actually this behavior seems intended:

F-Sy-H/F-Sy-H.plugin.zsh

Lines 59 to 62 in a9b3e37

if [[ ! -w $FAST_WORK_DIR ]]; then
FAST_WORK_DIR="${XDG_CACHE_HOME:-$HOME/.cache}/fsh"
command mkdir -p "$FAST_WORK_DIR"
fi

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

ss-o commented

Actually this behavior seems intended:

F-Sy-H/F-Sy-H.plugin.zsh

Lines 59 to 62 in a9b3e37

if [[ ! -w $FAST_WORK_DIR ]]; then
FAST_WORK_DIR="${XDG_CACHE_HOME:-$HOME/.cache}/fsh"
command mkdir -p "$FAST_WORK_DIR"
fi

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> ?

Yes I am already planning this zi#156 🙃 :octocat:

ss-o commented
ss-o commented

@bew, check branch 25-cache, to test the behavior. 🤞

References:

F-Sy-H/F-Sy-H.plugin.zsh

Lines 54 to 61 in 35d051c

# Check if Zsh's cache directory exist.
if [[ -d $ZSH_CACHE_DIR ]]; then
# Use Zsh's default cache directory.
typeset -g FAST_WORK_DIR=${FAST_WORK_DIR:-${ZSH_CACHE_DIR}/fsh}
else
# Use common values to set default working directory.
typeset -g FAST_WORK_DIR=${FAST_WORK_DIR:-${XDG_CACHE_HOME:-$HOME/.cache}/fsh}
fi

zi wait'!' lucid for ver'25-cache' \
  atinit"FAST_WORK_DIR=~/.cache/anyPath; zicompinit; zicdreplay" \
    z-shell/F-SY-H

Additionally ZSH_CACHE_DIR can be used. I plan to set it for all plugins, extensions, etc.

bew commented

#26 is working well, 👍

bew commented

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, …)

ss-o commented

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 :octocat:

ss-o commented

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. ⏲️