fix(settings): distinguish unset known settings from unknown ones

[jdx]

Summary

• mise settings get <key> walked the serialized current settings to look up a value, but Option<T> fields that are None are skipped by TOML serialization. That made unset-but-known settings indistinguishable from typos — both returned Unknown setting.
• Now: when the walk fails, check SETTINGS_META for the full key. If known, emit Setting [<key>] is not set; otherwise keep Unknown setting.

Reported in #9817.

Before

$ mise settings get python.compile
mise ERROR Unknown setting: python.compile
$ mise settings get not.a.real.setting
mise ERROR Unknown setting: not.a.real.setting

After

$ mise settings get python.compile
mise ERROR Setting [python.compile] is not set
$ mise settings get not.a.real.setting
mise ERROR Unknown setting: not.a.real.setting

Test plan

• mise settings get python.compile → Setting [python.compile] is not set (exit 1)
• mise settings get cargo.registry_name → Setting [cargo.registry_name] is not set (exit 1)
• mise settings get abcdefg → Unknown setting: abcdefg (unchanged)
• mise settings get legacy_version_file → true (unchanged)
• mise settings get python (parent key) → inline table (unchanged)
• E2E cli/test_settings_set extended and passing

🤖 Generated with Claude Code

---

Note

Low Risk
Low risk: small change to mise settings get error handling plus updated e2e expectations; main impact is different user-facing error text for missing known keys.

Overview
mise settings get now distinguishes between a known setting that is currently unset vs a truly unknown key by consulting SETTINGS_META when a lookup fails.

E2E CLI tests are updated/extended to assert the new Setting [<key>] is not set error for known-but-unset keys (including dotted keys), while keeping Unknown setting for typos.

^{Reviewed by Cursor Bugbot for commit 5186233. Bugbot is set up for automated code reviews on this repo. Configure here.}

[greptile-apps]

Greptile Summary

This PR fixes mise settings get so that known settings whose values are None (and therefore absent from TOML serialization) return a distinct error instead of the generic "Unknown setting" message.

• src/cli/settings/get.rs: When the TOML walk fails to find a key, is_known_setting now consults SETTINGS_META — checking for an exact key match or any key with that prefix — and emits \"Setting [<key>] is not set\" for valid-but-unset settings, keeping \"Unknown setting\" only for genuinely unrecognised keys.
• E2E tests (test_settings_set, test_settings_unset): Three new assertions cover a leaf-level typo, a valid unset dotted key, and a second plugin's unset key; the unset test is updated to match the new message.

Confidence Score: 5/5

Safe to merge — only the error message path of mise settings get is touched, and new E2E tests guard the new behaviour.

The change is narrow: it only affects the error-handling branch in the TOML walk (no success path is modified), and is_known_setting is a pure read of a static map. The three new E2E assertions directly cover the fix, including the typo-versus-unset distinction. No data, config, or runtime behaviour is altered for any previously-working call.

No files require special attention.

Important Files Changed

Filename	Overview
src/cli/settings/get.rs	Adds is_known_setting helper using SETTINGS_META to distinguish unset-but-valid keys from unknown ones; walk logic is correct for full and partial paths
e2e/cli/test_settings_set	Extends E2E test with three new assertions: typo in dotted key, known-but-unset dotted key, and a second plugin's unset setting
e2e/cli/test_settings_unset	Updates expected error message for python.compile after unset to match new "Setting [] is not set" wording

_{Reviews (3): Last reviewed commit: "test(settings): update test_settings_uns..." | Re-trigger Greptile}

[gemini-code-assist]

Code Review

This pull request enhances the mise settings get command to distinguish between valid but unset settings and entirely unknown settings, including new E2E tests for these cases. Feedback from the review highlights that the current check only recognizes leaf settings, causing organizational groups to still be reported as unknown. The reviewer suggested a more robust check to include these groups and recommended standardizing error message formatting by consistently using brackets for setting keys.

[gemini-code-assist]

The current check only identifies leaf settings as 'known'. Organizational groups (e.g., cargo, python) will still report as Unknown setting if they contain no set values, which is inconsistent with the goal of distinguishing known settings from typos.

Additionally, the error messages use different formatting styles (brackets vs. no brackets, and different phrasing). It is better to use a consistent style for both types of errors. Using brackets for the key is consistent with other error messages in the codebase.

Suggested change

	} else if SETTINGS_META.contains_key(self.setting.as_str()) {
	bail!("Setting [{}] is not set", self.setting);
	} else {
	bail!("Unknown setting: {}", self.setting);
	} else if SETTINGS_META.keys().any(|k| k == &self.setting || k.starts_with(&format!("{}.", self.setting))) {
	bail!("Setting [{}] is not set", self.setting);
	} else {
	bail!("Unknown setting: [{}]", self.setting);

[gemini-code-assist]

If the error message for unknown settings is updated to include brackets for consistency, this test case should be updated to match the new output.

assert_fail "mise settings get abcdefg" "mise ERROR Unknown setting: [abcdefg]"

[gemini-code-assist]

Code Review

This pull request improves the error reporting for the settings get command by distinguishing between unknown settings and settings that are valid but currently unset. It introduces a check against SETTINGS_META to provide more specific error messages. The review feedback suggests enhancing the test suite with a case for settings that have a valid prefix but an invalid leaf name to ensure the 'Unknown setting' logic handles these scenarios correctly.

[gemini-code-assist]

To fully verify that the logic correctly distinguishes between unset known settings and actual typos (unknown settings), it is recommended to add a test case where a key has a valid prefix but an invalid leaf name (e.g., python.compyle). This ensures that the else block in src/cli/settings/get.rs is correctly reached when the full key is not present in SETTINGS_META.

assert_fail "mise settings get abcdefg" "mise ERROR Unknown setting: abcdefg"
assert_fail "mise settings get python.compyle" "mise ERROR Unknown setting: python.compyle"
assert_fail "mise settings get python.compile" "mise ERROR Setting [python.compile] is not set"
assert_fail "mise settings get cargo.registry_name" "mise ERROR Setting [cargo.registry_name] is not set"

[github-actions]

Hyperfine Performance

mise x -- echo

Command	Mean [ms]	Min [ms]	Max [ms]	Relative
mise-2026.5.6 x -- echo	27.9 ± 2.0	22.9	33.4	1.00
mise x -- echo	28.9 ± 2.3	23.1	34.9	1.04 ± 0.11

mise env

Command	Mean [ms]	Min [ms]	Max [ms]	Relative
mise-2026.5.6 env	27.6 ± 2.2	22.2	34.1	1.00
mise env	28.3 ± 2.3	22.5	36.6	1.02 ± 0.12

mise hook-env

Command	Mean [ms]	Min [ms]	Max [ms]	Relative
mise-2026.5.6 hook-env	28.5 ± 2.2	23.2	37.2	1.00
mise hook-env	29.4 ± 2.4	23.7	39.3	1.03 ± 0.11

mise ls

Command	Mean [ms]	Min [ms]	Max [ms]	Relative
mise-2026.5.6 ls	24.2 ± 1.9	19.7	28.6	1.00
mise ls	25.2 ± 2.1	19.6	31.9	1.04 ± 0.12

xtasks/test/perf

Command	mise-2026.5.6	mise	Variance
install (cached)	159ms	159ms	+0%
ls (cached)	91ms	88ms	+3%
bin-paths (cached)	89ms	93ms	-4%
task-ls (cached)	641ms	646ms	+0%