Settings drawer covers the surface it configures

[flyingrobots]

Reported from live use.

The settings drawer occludes the gutter, so a setting like gutter dimming can not be evaluated while changing it. Configuring something you can not see is a design failure, not a preference.

Options raised

1. Move the drawer out of the way of whatever the focused setting affects
2. Replace the drawer with a modal dialog
3. Split the screen vertically and host settings in their own buffer on one side, leaving a live editor visible on the other

Option 3 is the most interesting and the largest; it also makes settings a normal buffer rather than a bespoke surface.

Acceptance

• Every setting can be observed taking effect while it is being changed
• Whatever the chosen shape, it is recorded as a design decision rather than an incidental layout change

[flyingrobots]

Recommendation: vertical split, settings as a real buffer

Of the three options in the description, I would take 3.

Why not the modal (option 2): it still covers the thing being configured, just with different geometry. It does not solve the stated problem, it relocates it.

Why not moving the drawer (option 1): the drawer would have to know which surface each setting affects and dodge it. That is bespoke logic per setting, and it breaks the moment someone adds one. It also cannot work for a setting affecting the whole editor surface — there is nowhere to dodge to.

Why the split: vi already does exactly this. :options opens a genuine buffer navigated with normal motions and toggled with <CR>. It is not a widget. That precedent matters here for a structural reason rather than an aesthetic one: settings stop being a special surface. Existing navigation, search and the gutter all work inside it for free, and there is less bespoke code, not more. A live editor stays on the other half, so the gutter can be watched while it is being toggled — the problem disappears rather than being worked around.

The honest cost: toggles in a text buffer are clunkier than a purpose-built list, and it needs a line-oriented interaction (<CR> toggles the setting on the cursor line). Vi's answer has held up for thirty years, so I would take that trade.

Related, and probably the same conversation

#317 found that gutter dimming is expressed only as ANSI SGR 2 "faint", which many terminals ignore — the setting is correct in code and invisible on screen. It cannot be evaluated while the drawer covers the gutter and it may not be visible even when uncovered.

Fixing the surface without fixing the token makes the setting observable but still inert. Worth sequencing #317 first, or deciding to drop that particular setting, before rebuilding the surface around it.

No code change; recording the recommendation so the decision has a written basis.