[FEATURE]: TUI plugins have no way to read or drive the prompt

[iceteaSA]

Feature hasn't been suggested before.

• I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

TUI plugins can render into slots, but they cannot read what the user is typing, edit it, move the cursor, or annotate a span of it. Anything that wants to complete, rewrite, validate, or highlight prompt text has no supported surface — the TextareaRenderable is internal to the prompt component.

Suggested behaviour

A plugin-facing prompt facade: read prompt state, replace a text range, drive the cursor, draw extmarks (underlined spans), and subscribe to prompt/cursor changes.

The awkward part is lifetime, and it is worth designing for rather than discovering later. The prompt remounts on session switches and route changes, so a plugin that captured a ref at load time is holding a destroyed controller. A facade that hands out the component ref directly will produce crashes in plugin code that looks correct.

Related edges that need an explicit answer rather than incidental behaviour:

• what a range replacement does when start > end
• whether offsets are byte, codepoint, or display-width, and how they snap to grapheme boundaries
• whether an existing extmark survives an edit that overlaps it
• what a screen-coordinate lookup returns when the prompt is unmounted or not yet laid out

Version

v1.18.5

Additional context

PR #38955 implements this (draft — the API shape is worth maintainer input before it becomes public surface).

[pescao0]

Would you prefer the ordering and atomicity semantics below to be incorporated into #38955, or discussed as a separate contribution?

I have a local v1.18.18 prototype of a host-owned transform registry that keeps existing session_prompt wrappers mounted. The reusable contract provides deterministic transform order, immutable drafts and context, per-draft serialization and same-revision coalescing, stale revision and fingerprint rejection, a single atomic host commit, and idempotent abort and disposal with plugin-scoped cleanup. Focused tests and a real-TUI coexistence check with an existing session_prompt wrapper pass.

This is only about generic plugin infrastructure, not the app-specific consumer. I will not open a competing PR before guidance and am happy to adapt the prototype to #38955 if that direction is preferred.

[iceteaSA]

Sorry for the slow reply — and the answer changed while it sat: #38955 was closed by the inactivity bot on Aug 26 (older than a month, fewer than two reactions). That's not a maintainer decision on the approach, but it does mean there's nothing to fold into. Open your own PR.

Your scope is also broader than mine was, so I don't think it wants to be the same PR anyway. #38955 was a prompt facade — read prompt state, edit text, drive the cursor, draw extmarks, and survive the remount problem (the prompt remounts on session switch, so a plugin holding a ref from load time has a destroyed controller; the ref lives on a context and api.prompt.ref() reads the live one). What it deliberately did not provide is any contract for multiple plugins transforming the same prompt: no ordering, no coalescing, no atomic commit. Yours is that missing layer.

Two things from my branch that might save you time, both lifetime-related rather than ordering-related:

• Guarded accessors (packages/tui/src/prompt/display.ts) — extmark calls no-op against a destroyed renderable instead of throwing, because a stale ref is the normal case, not the exceptional one.
• offsetToScreen returns null when the prompt is unmounted or not yet laid out, so overlay positioning gets an explicit "cannot answer" rather than a plausible wrong coordinate.

Branch is iceteaSA:tui-prompt-facade if any of it is useful — take it with no attribution needed. I'll review yours when it's up.

[pescao0]

Thanks, that distinction helped. I opened #46233 as the first of two focused draft PRs. This slice contains only the generic coordinator core and its tests; the follow-up will expose the plugin API and wire TUI host lifecycle handling.

I kept the prompt facade, extmarks, and screen-coordinate API outside this slice. I would appreciate your review of the coordinator semantics when you have time.