v1.1.1
[1.1.1] - 2026-07-16
A macOS config-path fix, from an outside report.
#372, filed by
@thachck, reported that gwm ignored
~/.config/gwm/config.toml. The docs promised that path, but on macOS gwm
resolved the user-level global config through dirs::config_dir() —
~/Library/Application Support/gwm/config.toml — so a config placed where the
docs said was silently ignored unless $XDG_CONFIG_HOME was set (%APPDATA%
on Windows). Chasing it surfaced the identical bug for the user-level alias
file; both now go through one resolver so they can't drift apart again.
Fixed
-
The user-level global config is read from the documented
~/.configpath
on every platform (#372,
#373; reported by
@thachck). Resolution is now: an explicit
$XDG_CONFIG_HOMEwins outright, otherwise the first existing of
~/.config/gwm/config.tomlthen the platform config dir (Application Supporton macOS,%APPDATA%on Windows), with the canonical~/.config
path reported when neither exists. A non-UTF-8$XDG_CONFIG_HOMEis now read
viavar_os, so it can no longer be dropped and masked by~/.config. On
Linux the two candidates coincide, so resolution is byte-for-byte unchanged. -
The user-level alias file (
~/.config/gwm/aliases.toml) resolves the same
way (#374,
#375). It shared the old
dirs::config_dir()resolution, so it too was ignored at the documented
~/.configpath on macOS and Windows. Both files now share one resolver
(resolve_gwm_config_file) so the two paths cannot drift apart again.
Compatibility
No breaking change — both are bug fixes to path resolution. An explicit
$XDG_CONFIG_HOME still wins outright, and an existing Application Support /
%APPDATA% config or alias file keeps working (the platform dir stays a
fallback), so no user action is required. macOS and Windows users who followed
the docs and placed their files under ~/.config will simply have them picked
up now.
The user-level trust ledger (trust.toml) intentionally stays at
dirs::config_dir(): it is machine-local state gwm writes itself, and moving
it would force a re-trust of every repo.