Skip to content

Improve statusline preset ordering and model display behavior #4633

Description

@shenyankm

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions