Skip to content

Add on-demand and hidden input window display modes - #262

Merged
dnouri merged 1 commit into
dnouri:masterfrom
SayreBlades:input-window-on-demand
Aug 9, 2026
Merged

Add on-demand and hidden input window display modes#262
dnouri merged 1 commit into
dnouri:masterfrom
SayreBlades:input-window-on-demand

Conversation

@SayreBlades

Copy link
Copy Markdown
Collaborator

Summary

Adds a pi-coding-agent-input-window-display user option so the input window can be ephemeral rather than always-on, enabling a chat-centric workflow where the input pane appears only while composing.

  • always (default, unchanged): the input window is shown whenever the session is displayed.
  • on-demand: the input window is shown at launch, hidden after each send, and reopened with the new M-x pi-coding-agent-open-input; pi-coding-agent-toggle / redisplay show chat-only.
  • hidden: like on-demand, but a session also launches chat-only — the input never appears until you summon it (i/a under Evil, or M-x pi-coding-agent-open-input).

Motivation

Today the input pane is permanent chrome even when you're only reading agent output (scrolling tool output, following streaming thinking, reviewing a diff). On a small laptop that's a meaningful chunk of the chat you're actually trying to read, and the input buffer is useful only for the few seconds you spend composing a prompt.

The only current recourse for a chat-centric view is fragile user advice:

(defadvice! my/pi-send-close-input :after #'pi-coding-agent-send
  ;; delete the input window after sending
  ...)

That advice is incomplete in two ways:

  1. It can't make launch chat-only. Launch always goes show-session-buffersdisplay-buffers, which unconditionally splits. So after the advice closes the input on send, the next focus/launch re-opens the input split — the user closes it by hand over and over.
  2. It duplicates the package's window-management internals (soft-dedication of the input window, frame-local window queries, re-selecting the chat window, the window-parent guard) and silently breaks when those internals move.

Additionally, non-Evil users have no way to dismiss the input at all today — only the Evil integration has pi-coding-agent-evil-close-input (q).

This PR makes the input a first-class transient pane — completing the existing dismissable-input design (Evil i/a to focus, q to close) — and lets users delete their hand-rolled advice in favor of one variable.

Changes

  • New option pi-coding-agent-input-window-display (always / on-demand / hidden).
  • New command pi-coding-agent-open-input: focus an existing input window, else split one below the chat window, else restore the full layout.
  • pi-coding-agent--display-buffers gains an optional chat-only argument; the input-splitting logic is extracted into a pi-coding-agent--split-input-below-chat helper (reused by open-input).
  • New predicate pi-coding-agent--input-window-on-demand-p groups the two ephemeral modes (on-demand and hidden) for shared behavior: hide after send, and chat-only on redisplay/toggle.
  • pi-coding-agent--show-session-buffers honors hidden (chat-only launch). Note: when both windows are already visible, the existing layout is preserved and input is focused — it never yanks an intentionally-opened input away.
  • Hide-after-send wired into pi-coding-agent-send via pi-coding-agent--maybe-hide-input-window.
  • Bugfix: pi-coding-agent--best-input-window could return a non-input window when no input window was visible; it now returns nil. Under on-demand/hidden, "no input window visible" is a normal state rather than an error state, so this becomes load-bearing.

Design notes

  • One enum, not two booleans. Parallel to pi-coding-agent-thinking-display and pi-coding-agent-project-trust-policy (both symbol enums). hidden reuses on-demand's ephemeral behavior; the only delta is the launch window, which is the dedicated knob this exposes. A cross-product of booleans (hide-after-send × chat-only-at-launch) would be harder to read and extend (side-by-side / input-only layouts later).
  • Naming/values are negotiable — happy to adjust to maintainer preference.

Compatibility & testing

  • Default is alwaysno behavior change for existing users.
  • pi-coding-agent--display-buffers's new arg is optional and backward compatible.
  • Six unit tests added/updated in pi-coding-agent-ui-test.el (batch-runnable via make test-ui), all passing:
    • chat-only launch under hidden
    • send-hides under on-demand and under hidden
    • send-keeps under always
    • open-input splits-below-chat and focuses-existing-input
    • display-buffers chat-only
  • Byte-compiles clean with byte-compile-error-on-warn; checkdoc clean on changed source files.

Window-layout logic is unit-covered; make test-gui is unaffected by this change.

New pi-coding-agent-input-window-display user option with three values:

- `always' (the default): the input window is shown whenever the
  session is displayed (unchanged behavior).
- `on-demand': the input window is shown at launch, hidden after each
  send, and reopened with the new pi-coding-agent-open-input command.
  Redisplaying an existing session (e.g. via pi-coding-agent-toggle)
  shows only the chat window.
- `hidden': like `on-demand', but a session also launches with only
  the chat window visible, so you start in a chat-centric view and
  open the input only when composing.

Also fix pi-coding-agent--best-input-window returning a non-input
window when no input window was visible.
@SayreBlades
SayreBlades force-pushed the input-window-on-demand branch from e312579 to 91086c6 Compare August 9, 2026 18:49
@SayreBlades
SayreBlades requested a review from dnouri August 9, 2026 19:45

@dnouri dnouri left a comment

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry but this is outright bullshit. The author of this PR has not understood what this project is about at all. But thanks I guess.

@dnouri
dnouri merged commit a7b533f into dnouri:master Aug 9, 2026
11 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants