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

[bew]

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]

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]

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]

Thanks, will get back to this after triage.

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

[bew]

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]

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 🙃

[ss-o]

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

[ss-o]

@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]

#26 is working well, 👍

[bew]

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]

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

[ss-o]

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