Emacs frontend for Igor Chubin's wttr.in weather service https://git.cjennings.net/emacs-wttrin/atom?h=release%2F0.4.0 2026-07-03T02:37:06+00:00 2026-07-03T02:37:06+00:00 Craig Jennings c@cjennings.net 2026-07-03T02:37:06+00:00 urn:sha1:8b461ecd3d4fae3be0a93523d19932e0a3d21c6c 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. 2026-07-01T17:51:28+00:00 Craig Jennings c@cjennings.net 2026-07-01T17:51:28+00:00 urn:sha1:f2d3f6c6586ede7f757ca74ea699982562f069a7 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. 2026-06-26T17:25:41+00:00 Craig Jennings c@cjennings.net 2026-06-26T17:25:41+00:00 urn:sha1:ee8fdeb692d666c12ce068a2b1ee90e9451ac892 Making a location the default saved it and dropped the favorite name from history, but not the underlying query. For an alias whose query differs from its name, that query lingered as a separate history candidate. Both saving branches now drop the name and the query, matching wttrin-save-location. 2026-06-26T16:52:48+00:00 Craig Jennings c@cjennings.net 2026-06-26T16:52:48+00:00 urn:sha1:06143c61c3782b24c738587ae5e1f427ceb0518c Pressing d cleaned the location from history, but saving with s did not. A place saved under a friendly name kept its raw query as a separate history candidate, and removing the saved entry let that query resurface in the picker. wttrin-save-location now drops the saved name and its query from history, and wttrin-remove-location drops both the removed name and its query (captured before removal). A new wttrin--drop-from-location-history helper does the work. A place now lives in the directory or in history, never both. 2026-06-26T16:39:36+00:00 Craig Jennings c@cjennings.net 2026-06-26T16:39:36+00:00 urn:sha1:9459a0b30f86adb9066312672c7bd96e70bc1f6f Pressing d on a typed or aliased location set the favorite but never added it to wttrin-saved-locations, so the default persisted only as the favorite string, not as a named directory entry. The coordinate branch already saved. The typed/alias branch did not. The typed/alias branch now puts the location into the directory before promoting it, so a typed default like "Reykjavik" persists as a ("Reykjavik" . "Reykjavik") entry. An empty-name coordinate detection still keeps the raw coordinates without saving an entry. 2026-06-26T14:53:18+00:00 Craig Jennings c@cjennings.net 2026-06-26T14:53:18+00:00 urn:sha1:55ee8158a1f85bb532a24d752f9ef409192a924c A saved location carries a display name distinct from its query target ("Mom's House" maps to coordinates or an address), stored in a savehist-persisted wttrin-saved-locations alist. The name shows everywhere the place appears (picker, buffer header, mode-line tooltip) while wttr.in is still queried by the target. Management commands wttrin-save-location, wttrin-rename-location, and wttrin-remove-location edit the directory, with refuse-on-collision rename and a favorite-fallback warning on remove. In the weather buffer, s/r/x reach those commands and d names a detected location before promoting it to the default. The footer is two columns: a "This view" column (another, refresh, quit) and a "Saved locations" column (save, make default, rename, remove). The buffer anchors to the top so the forecast isn't scrolled out of view in a short window. The mode-line follows favorite changes immediately rather than waiting for the next scheduled fetch, and its hover tooltip shows the saved name instead of the raw query. History holds named entries only: raw coordinate detections and saved names stay out of it.