fix(editor): use subl as Sublime PATH command

[americos]

Why

Package sublime-text-4 puts /usr/bin/subl on PATH, not sublime_text. omarchy-default-editor stored and checked sublime_text, so after install Omarchy still treated Sublime as missing and omarchy-launch-editor fell back to nvim. Defaults → Editor never listed it. Fixes #9643.

Scope

• Store/check PATH command subl; keep menu selection and gtk-launch desktop id sublime_text (install path is already correct — do not change it).
• Map stored sublime_text → subl in omarchy-launch-editor so existing defaults still launch.
• Menu checked-state compares to subl.
• Test mock: sublime-text-4 → subl (the previous mock lied and mapped to sublime_text).

Tradeoffs

Store the PATH command, not the desktop id. One extra alias in the case statement (sublime_text | subl) and a one-line launch remap. Avoids changing the install/gtk-launch id, which is correct.

Blast radius

Default-editor selection, launch, and the Defaults menu check for Sublime only. Other editors unchanged. Existing stored sublime_text still launches via the remap.

Verification

bash test/shell.d/default-apps-test.sh — all passed, including "editor defaults install every missing editor before selection". No Omarchy GUI repro here (GNOME box, not Omarchy/Hyprland).

Fixes #9643

[omarchybot]

Reviewed by Claude Opus 5, with an independent second opinion from Codex at xhigh reasoning. Tests were executed on a disposable Omarchy VM rather than only read.

Your scope note is right and the premise holds. I pulled the AUR sublime-text-4 PKGBUILD: install -Dm755 "${pkgname}.sh" "${pkgdir}/usr/bin/subl" is the only thing it puts in /usr/bin, while sublime_text remains the desktop id (/usr/share/applications/sublime_text.desktop) and the Hyprland window class at default/hypr/apps/system.lua:18. Leaving omarchy-menu.jsonc:232 and that Lua rule alone is correct. No production call site is missed.

One real defect, fixed and pushed as 7109662. The branch dropped bin/omarchy-default-editor, bin/omarchy-launch-editor and test/shell.d/default-apps-test.sh from mode 755 to 644. That is not cosmetic here: omarchy-default-editor is reached through PATH — by the router, which only registers executable files (bin/omarchy:317) and requires -x to resolve directly (bin/omarchy:402), by the menu's checked guard, and by default-apps-test.sh, which puts the repo's own bin/ on PATH. PATH lookup skips a file without the executable bit, so the editor suite died at its very first case with the script silently unfindable — 0 passed, 1 failed at missing code opens its default installer in a terminal, before it ever reached Sublime. test/cli cannot catch this: its -x assertion covers five hard-coded commands and its metadata lint selects on -type f -executable, so a non-executable bin is skipped rather than flagged. Nothing in the diff asked for the mode change, so it is worth checking whatever wrote the files locally.

Ran on the worker at 28abc4a, before the fix:

• ./test/cli — 116 passed, exit 0
• ./test/shell.d/default-apps-test.sh — 0 passed, 1 failed, exit 1
• ./test/shell.d/menu-test.sh — 121 passed, exit 0

And at 7109662, after it:

• ./test/cli — 116 passed, exit 0
• ./test/shell.d/default-apps-test.sh — 11 passed, 0 failed, exit 0
• ./test/shell.d/menu-test.sh — 121 passed, 0 failed, exit 0

One thing left open, which #9656 does not handle either: anyone who already selected Sublime has sublime_text in ~/.local/state/omarchy/defaults/editor. Your remap in omarchy-launch-editor means it still launches, which is the half that matters — but omarchy-default-editor with no arguments still prints sublime_text, so the checked comparison against subl is false and the row shows unticked until they reselect. Which way to close that (normalize the getter, accept both values in checked, or add a migration under migrations/) is a design choice, so I have left it rather than pushing one.

Codex agreed with the mode finding, which I had already read out of the diff, and added the mechanism I had not looked at: the router's own -x filter at bin/omarchy:317 and :402, which is why a 644 script disappears from omarchy <group> routing as well as from PATH. It rejected nothing else and found no further defect. Its independence is not currently guaranteed, since it can read this session's own transcript.

#9656 fixes the same issue with the same production change, but adds a when guard on the Defaults row that fails menu-test.sh and removes the install-on-select path, and leaves default-apps-test.sh asserting the old name. Which to take is the maintainer's call, not mine.

[americos]

Addressed the leftover checked-state: omarchy-default-editor with no args now remaps stored sublime_text to subl, same as launch. The Defaults row ticks without a migration. Covered in default-apps-test.sh (legacy sublime_text default reports as subl). Scripts kept mode 755. 1407271

[omarchybot]

Re-reviewed at 1407271. The one thing left open from the last pass is closed.

omarchy-default-editor with no arguments now remaps a stored sublime_text to subl at bin/omarchy-default-editor:21, so the Defaults → Editor row ticks for anyone who selected Sublime before this branch, and no migration is needed. Only two things read ~/.local/state/omarchy/defaults/editor — that getter and bin/omarchy-launch-editor:22 — and both remap now. Nothing else consumes the getter's output except the checked guards in omarchy-menu.jsonc:163-170 and shell/plugins/menu/MenuModel.js, which caches it verbatim, and there is no XDG handler derived from the editor default: default/applications/mimeapps.list:33 pins text/plain to nvim.desktop on its own. The stored string itself stays sublime_text until the setter next writes at line 60, which is untidy but has no visible consequence.

The new test is real coverage rather than a green light. Deleting line 21 on the worker and re-running turns it red on exactly that assertion — 9 passed, 1 failed, not ok - stored sublime_text reports as subl — and passes again when restored.

The rest of the rename holds together. bin/omarchy-default-editor:50 still keys the installer on selection, so Sublime still installs sublime-text-4; omarchy-menu.jsonc:232 still hands gtk-launch the desktop id sublime_text; the Hyprland window class at default/hypr/apps/system.lua:18 is untouched. I pulled the AUR PKGBUILD rather than take the premise on trust: install -Dm755 "${pkgname}.sh" "${pkgdir}/usr/bin/subl" is the only thing that reaches /usr/bin, the binary itself stays in /opt/sublime_text/, and the desktop file is sublime_text.desktop. So subl is on PATH from a stock install of that package, not from a symlink that may or may not exist.

Ran on a disposable Omarchy VM at 1407271, not merely read:

• ./test/cli — 116 passed, exit 0
• ./test/shell.d/default-apps-test.sh — 12 passed, 0 failed, exit 0
• ./test/shell.d/menu-test.sh — 121 passed, 0 failed, exit 0
• ./test/shell.d/editor-env-test.sh — 3 passed, 0 failed, exit 0

Reviewed by Claude Opus 5, with a second opinion from Codex at xhigh reasoning. Codex found no defect and agreed with the conclusions above, which I had already written down, so its independence is not currently guaranteed. It did contribute one thing I had not worked through: the && form at lines 21 and 22 carries no exit-status hazard even under an inherited bash -e, because a failed first command in an AND-list is exempt from errexit.

Nothing pushed this pass; the branch is clean as it stands. It is waiting on the maintainer, who still has to choose between this and #9656. That one makes the same production change to the case arm and the launcher but has no getter remap, so a pre-existing Sublime user's row stays unticked; it leaves default-apps-test.sh asserting the old name; and it adds a when guard on the Defaults row that test/shell.d/menu-test.sh:260 rejects outright, since that assertion requires every Defaults entry to carry no when.