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-02T02:57:03+00:00 Craig Jennings c@cjennings.net 2026-07-02T02:57:03+00:00 urn:sha1:6c808ff4a4c54d543e065b722bc8517fe5141b45 The tooltip showed current conditions only. I added wttrin-mode-line-tooltip-forecast-days (default 0, capped at wttr.in's three days). When positive, the mode-line refresh also fetches ?format=j1 and caches the parsed day list, and the tooltip renders one line per day between the conditions and the age line: Today / Tomorrow / weekday label, min-max temps in the configured unit, and the midday description. A failed or malformed forecast fetch keeps the previous forecast and never disturbs the main fetch. 2026-07-01T18:12:39+00:00 Craig Jennings c@cjennings.net 2026-07-01T18:12:39+00:00 urn:sha1:ad22b39fb5661a6662865c0e88dcfb0d1627eeb4 2026-07-01T18:07:26+00:00 Craig Jennings c@cjennings.net 2026-07-01T18:07:26+00:00 urn:sha1:0e306183e814659798f24573389a46b0d2b8e29a wttrin-query inserted the "Loading weather for ..." placeholder but never centered it, leaving that to window-configuration-change-hook. On an `a` switch the *wttr.in* buffer is already displayed, so the hook doesn't fire. The placeholder kept the previous weather block's window margin and rendered off-center until the new weather arrived. I moved the placeholder rendering into wttrin--render-loading-placeholder, which centers it explicitly via wttrin--update-layout. It no longer depends on the hook, so the placeholder is centered on the first open and through every switch. 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-28T10:57:26+00:00 Craig Jennings c@cjennings.net 2026-06-28T10:57:26+00:00 urn:sha1:b1aca874b9a2b5282c0cc83bd4fece981a94e19c C-h v wttrin-geolocation-command now mentions examples/geolocation/, so the ready-to-adapt scripts are discoverable from inside Emacs, not just the README. 2026-06-28T10:52:52+00:00 Craig Jennings c@cjennings.net 2026-06-28T10:52:52+00:00 urn:sha1:95a5e130deb4c73242c370ce239b3ba9a97e6ef5 Restores the base height when a remap cookie exists, no-op without one. 2026-06-28T10:52:52+00:00 Craig Jennings c@cjennings.net 2026-06-28T10:52:52+00:00 urn:sha1:bcdb5889bc7f38ce1e87c495b6f186b62e45467a Add an "Auto-Fit and Centering" subsection to the README font settings: the weather block centers automatically, and wttrin-auto-fit-font (with the min/max floor and cap) opts into sizing the font to the window. 2026-06-28T10:42:00+00:00 Craig Jennings c@cjennings.net 2026-06-28T10:42:00+00:00 urn:sha1:16be44154cf823332332d1df995ae1ed50ff43c4 With auto-fit on, the one-line "Loading..." placeholder was sized to fill the window height (capped huge), and a reused buffer kept the previous weather's auto-fitted font while loading. Auto-fit now runs only once real weather has rendered, and the placeholder resets to the base font. 2026-06-28T08:11:45+00:00 Craig Jennings c@cjennings.net 2026-06-28T08:11:45+00:00 urn:sha1:da7ee0841924dfbd91c9a944e0bfeff6903bd8a1 wttrin--display-weather ran switch-to-buffer from the async callback, so a response arriving after the user moved to another buffer yanked them back to *wttr.in*. It now renders with set-buffer; selecting the buffer is the interactive command's job (wttrin-query already does it at invocation), so a late response updates the buffer in place without changing the selected window.