<feed xmlns='http://www.w3.org/2005/Atom'>
<title>emacs-wttrin/tests/test-wttrin-use-current-location.el, branch release/0.4.0</title>
<subtitle>Emacs frontend for Igor Chubin's wttr.in weather service
</subtitle>
<id>https://git.cjennings.net/emacs-wttrin/atom?h=release%2F0.4.0</id>
<link rel='self' href='https://git.cjennings.net/emacs-wttrin/atom?h=release%2F0.4.0'/>
<link rel='alternate' type='text/html' href='https://git.cjennings.net/emacs-wttrin/'/>
<updated>2026-07-01T17:51:28+00:00</updated>
<entry>
<title>fix: keep a d-set favorite from reverting to the init value on restart</title>
<updated>2026-07-01T17:51:28+00:00</updated>
<author>
<name>Craig Jennings</name>
<email>c@cjennings.net</email>
</author>
<published>2026-07-01T17:51:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.cjennings.net/emacs-wttrin/commit/?id=f2d3f6c6586ede7f757ca74ea699982562f069a7'/>
<id>urn:sha1:f2d3f6c6586ede7f757ca74ea699982562f069a7</id>
<content type='text'>
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.
</content>
</entry>
<entry>
<title>feat: add named-locations directory with display names</title>
<updated>2026-06-26T14:53:18+00:00</updated>
<author>
<name>Craig Jennings</name>
<email>c@cjennings.net</email>
</author>
<published>2026-06-26T14:53:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.cjennings.net/emacs-wttrin/commit/?id=55ee8158a1f85bb532a24d752f9ef409192a924c'/>
<id>urn:sha1:55ee8158a1f85bb532a24d752f9ef409192a924c</id>
<content type='text'>
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.
</content>
</entry>
<entry>
<title>feat: add external-command geolocation, opt-out, and example adapters</title>
<updated>2026-06-25T20:03:18+00:00</updated>
<author>
<name>Craig Jennings</name>
<email>c@cjennings.net</email>
</author>
<published>2026-06-25T20:03:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.cjennings.net/emacs-wttrin/commit/?id=7027cccea9eb7170ea0f08e1def3f979f2e59932'/>
<id>urn:sha1:7027cccea9eb7170ea0f08e1def3f979f2e59932</id>
<content type='text'>
These build on the current-location picker with the rest of the geolocation work.

wttrin-geolocation-command runs a command that prints {lat,lng} (and optionally an address) and queries wttr.in by those coordinates. IP geolocation only finds the network's exit point, which is wrong on a VPN or hotspot. A command that scans nearby WiFi resolves to street level. It runs asynchronously, falls back to the IP provider when unset or failing, and assumes nothing about the OS, so it's inert until set. When the command returns an address, wttrin shows it on a "Location:" line, so the resolved place is readable even though the fetch is by raw coordinates.

wttrin-use-current-location is a labeled command that sets the favorite to auto-detect, so the bare t value never has to be typed into init by hand.

wttrin-geolocation-enabled (default t) turns every geolocation surface off for anyone who wants that: the picker entry, the auto-detect favorite, and the command.

examples/geolocation/ ships two reference adapters for the command: google-geolocate.py (Google API, key via the environment or ~/.authinfo.gpg) and apple-wps.py (Apple's keyless WiFi positioning, which uses an undocumented endpoint, so read its caveat). Both are Python 3 standard library and scan via nmcli, with notes on adapting the scan to other systems.
</content>
</entry>
</feed>
