| |
|
|
|
|
| |
The load-time restore read `wttrin-state-file` at whatever path the option held when wttrin loaded. A `setopt` in a use-package `:config` block runs after that read, so `d` wrote the new file and the next start never opened it. The default reverted to the init value on every restart.
I gave the option a `:set` handler that stores the value and re-runs `wttrin--state-load` from the new path. `setopt`, `customize-set-variable`, and Customize all route through it. When the restore changes the effective favorite while the mode-line mode is on, the mode-line refreshes to the restored city. A plain `setq` after load still waits for the next restore, and the docstring now says so.
|
|
|
savehist rewrites its whole file on every save, keeping only the variables registered in the running process. Any Emacs that saved savehist without wttrin loaded (a batch tool, a session that never opened wttrin) silently deleted the persisted favorite and saved-location entries. A d-set default then reverted to the init value on the next restart.
The runtime favorite and directory now live in wttrin-state-file, written only by wttrin: write-through on every location command, atomic temp-file + rename, UTF-8 pinned both ways, read with read (never eval), versioned plist. Values restore at load and re-assert on savehist-mode-hook, so a stale legacy savehist restore can't clobber them. With no state file present, legacy savehist values are adopted and written once, so existing users migrate with zero steps. Search history stays on savehist. It's scrub-tolerant throwaway data, exactly what savehist is for.
Also: the README documents the mode-line tooltip forecast option, and the gitignore covers one more local tooling artifact.
|
