aboutsummaryrefslogtreecommitdiff
path: root/tests/test-system-lib-executable-find-or-warn.el
Commit message (Collapse)AuthorAgeFilesLines
* refactor(system-lib): extract cj/executable-find-or-warn from mail-configCraig Jennings2026-05-101-0/+80
Phase 2 of utility-consolidation, first commit per the spec's recommended order. `cj/mail--executable-or-warn' was the right pattern -- check executable-find, return the path, otherwise emit a clear `display-warning' naming the feature -- but it was trapped in mail-config and only mail callers benefited. Lift it into `cj/executable-find-or-warn' in system-lib.el with one new argument: an optional GROUP symbol that flows through to `display-warning' (defaulting to `cj/system-lib') so per-feature warning filters keep working. Mail callers pass `mail-config' explicitly. Migrate `cj/mail--mbsync-command' and `cj/mail-configure-smtpmail' to the new helper. Drop the local definition. Add `(require \='system-lib)' to mail-config.el per the spec's Phase 2 exit criterion ("consumer modules explicitly require system-lib"). Five Normal/Boundary tests cover the four return-shape cases (program found / program missing / warning content / default vs explicit group). Other consumers (prog-*.el, dirvish-config.el, browser-config.el) still call `executable-find' directly. Migrating them is a follow-up commit, audited per call site -- the spec flags some `:if' silent checks as intentional and they should NOT switch to the warning helper.