| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
| |
wttrin-favorite-location did two jobs: a defcustom the user sets in init, and the savehist-persisted value that `d`/make-default mutated. Setting it in init (setopt) clobbered the `d` choice on every startup. So a favorite promoted with `d` reverted to the init value after a restart, and the mode-line showed the wrong location's weather. wttrin-saved-locations had the same defect.
I split the two roles. The defcustoms stay as the init-set base. New savehist-persisted runtime vars, wttrin--favorite-override and wttrin--saved-locations-runtime, hold what `d`, save, rename, remove, and the geolocation commands write. Reads go through resolvers: wttrin--favorite-location returns the override or the configured favorite, and wttrin--saved-locations overlays the runtime directory on the configured one (runtime wins on a name collision). Init and `d` now write different variables, so neither clobbers the other.
Removing a saved location that only comes from init can't delete it, since the runtime removal has nothing to touch. The command now says so instead of reporting a removal that didn't happen.
There's no automatic migration. A favorite set in init is unaffected, and a favorite set only with `d` before this version is re-set once with `d`. The README documents the behavior.
|
| |
|
|
|
|
|
|
|
|
| |
Geolocation used to live in a separate command, so getting weather for where you are meant knowing a second command existed. I added a "Current location (detect)" entry pinned to the top of the M-x wttrin picker. Selecting it detects your location and shows its weather. If the guess is wrong (VPN, hotspot) the detected city is visible in the header, so you reopen the picker and type one. Press d to keep the detected city as the default.
The entry is pinned first through a completion table whose display-sort-function holds against completion frameworks that re-sort, and it never enters location history or the cache as a place.
A new wttrin-geolocation-enabled (default t) turns every geolocation surface off for users who want that: the picker entry, the auto-detect favorite, and the command. It stays on by default.
The older wttrin-set-location-from-geolocation command is now obsolete in favor of the picker. Its customize-save-variable persistence advice is replaced by savehist, which already carries the favorite across sessions.
|
| |
|
|
|
|
| |
Pressing d to promote a displayed location to the favorite changed wttrin-favorite-location but left the mode-line untouched. Its cache still held the old location's weather. The next scheduled refetch could be up to an hour away, so the hover tooltip kept showing the previous default.
wttrin--set-favorite-location now detects a real change and, when the mode-line is active, clears the stale cache and fetches the new location at once via a new wttrin--mode-line-refresh-now helper. The tooltip switches within seconds instead of waiting for the timer.
|
|
|
I bound d in the weather buffer to wttrin-make-default, which sets wttrin-favorite-location to the location on screen so it drives the mode-line and future sessions. The footer advertises "[d] to make default".
Persistence rides savehist, not the Emacs custom-variable mechanism: wttrin--savehist-register registers wttrin-favorite-location alongside the search history, at load and on savehist-save-hook. Enable savehist-mode and the favorite survives restarts.
Promoting a location drops it from the search history, the way wttrin-default-locations entries are kept out of history. The favorite shows in the picker instead: wttrin--completion-candidates prepends it when it's a string and not already a default, so it appears exactly once.
The setter only assigns the variable and trims history. It doesn't register with savehist itself, because savehist-additional-variables is unbound until savehist loads, so a direct add-to-list would error for users without savehist. Registration stays on the load and save-hook path.
|
