What would you like to be added?
Improve the built-in /statusline preset behavior so selected preset items are treated as a visible item set, while display order is controlled by a fixed built-in priority.
Expected behavior:
- Toggling a preset item off and then on should restore it to its priority position instead of appending it to the end.
- Preset rendering, preview, saved settings, and manually written settings should all use the same fixed ordering.
model-with-reasoning should remain first.
model-only should be displayed after model-with-reasoning.
model-with-reasoning and model-only should be allowed to display together.
- Other frequently used runtime fields, such as Git branch and context remaining, should appear earlier in the preset order.
Why is this needed?
The current behavior makes the statusline order depend on MultiSelect insertion order. When a user disables an item and enables it again, the item reappears at the end instead of its original logical position. This makes the statusline feel unstable and hard to scan.
Using a fixed priority order makes preset.items mean "which items are visible" rather than "the exact display order", which is more predictable for normal statusline usage.
Additional context
This is inspired by the focused statusline ordering used by oh-my-codex, where model/reasoning information appears first and high-frequency runtime information follows.
No new statusline items or settings schema changes are required.
Existing config id model should remain compatible, while the UI label can be shown as model-only.
What would you like to be added?
Improve the built-in
/statuslinepreset behavior so selected preset items are treated as a visible item set, while display order is controlled by a fixed built-in priority.Expected behavior:
model-with-reasoningshould remain first.model-onlyshould be displayed aftermodel-with-reasoning.model-with-reasoningandmodel-onlyshould be allowed to display together.Why is this needed?
The current behavior makes the statusline order depend on MultiSelect insertion order. When a user disables an item and enables it again, the item reappears at the end instead of its original logical position. This makes the statusline feel unstable and hard to scan.
Using a fixed priority order makes
preset.itemsmean "which items are visible" rather than "the exact display order", which is more predictable for normal statusline usage.Additional context
This is inspired by the focused statusline ordering used by oh-my-codex, where model/reasoning information appears first and high-frequency runtime information follows.
No new statusline items or settings schema changes are required.
Existing config id
modelshould remain compatible, while the UI label can be shown asmodel-only.