Module display 

Buffer display preferences (DESIGN.md §5.9).

When an ex-command produces a buffer (:lsp-status, :help foo, :diagnostics, picker accept, hover, …) it doesn’t open the buffer directly – it asks the App to display it under a BufferDisplayCategory. The App resolves the category to a concrete BufferDisplay (built-in default today; user- overridable via typed options in a follow-up) and dispatches to the matching surface: popup overlay, active pane replacement, or a fresh split.

Decoupling the what (the buffer) from the where (the display) means a single user preference – “I want LSP logs in a horizontal split, not a popup” – is one toggle, not a patch to every command that produces an LSP log buffer.

The taxonomy is by intent, not by command: adding a new :describe-symbol falls under the existing BufferDisplayCategory::HelpDescribe knob without a new category; adding a whole new feature (say git.log) is one new variant.

Enums

BufferDisplay

Where to put a buffer the App is about to display.

BufferDisplayCategory

Per-feature display preference. Each command that produces a buffer carries its category; the App resolves the category to a BufferDisplay via default_display (today) or a user-supplied override (follow-up).

BufferDisplayPreference

User-facing override for a BufferDisplay. Each BufferDisplayCategory gets a typed option keyed <category>.display whose value is one of these variants; the App’s resolver maps the variant to the matching BufferDisplay. Default means “use the built-in default for this category” — the fallback when the user hasn’t set the option explicitly.

Functions

default_display

Built-in default for each category. Matches today’s hard-coded behaviour so the dispatch refactor lands without observable behaviour changes; user overrides layer on top in a follow-up slice.