Should the TUI composer stay visible while reading scrollback?

[me2seeks]

Maka's TUI uses the terminal's native scrollback for conversation history. The composer and status line live at the end of that output.

This works naturally while following the latest response, but it becomes awkward when reading older content. A user can scroll upward to inspect an earlier answer or a long tool result, but after reading it they must scroll all the way back to the bottom before they can see the composer and continue typing.

Question

Should the TUI keep the input composer and status line visible at the bottom of the viewport while the user scrolls through conversation history?

The intended experience would be:

• conversation history can scroll independently;
• the composer remains available, so the user can start typing from any reading position;
• the current status remains visible;
• new output does not unexpectedly take the user away from the part of history they are reading.

This is adjacent to #3811, which discusses making permission mode more visible in the input area, but the question here is about whether the whole input/status area should remain anchored.

Trade-offs

The current native-scrollback model preserves normal terminal selection, copying, and scrollback behavior. Keeping a footer fixed may require an application-owned transcript viewport or another split-layout approach, which would also need clear behavior for mouse wheels, Page Up/Down, selection, resizing, and long or streaming output.

A fixed footer also consumes viewport rows in small terminals. It may be worth keeping only the composer fixed, or collapsing the status line while the user is reading history.

Questions to settle

1. Is returning to the bottom before typing a meaningful usability problem in real TUI use?
2. Should both the composer and status line remain fixed, or only the composer?
3. If the user starts typing while viewing older history, should the transcript stay in place or jump to the latest message?
4. When new model or tool output arrives, should the TUI preserve the user's reading position and show an unread indicator?
5. Can this be achieved without losing the terminal's native selection, copying, and scrollback behavior?

This discussion is about the desired interaction first; it does not assume a particular rendering or scrolling implementation.

AI assistance disclosure: Drafted and published with Codex at the author's direction.

[Astro-Han]

Thanks for laying out the trade-offs so explicitly — the question of what happens to selection, copying, and scrollback is exactly the right one to ask first.

One fact that changes this discussion's cost math: the fullscreen path already exists in Maka's pinned TUI dependency. @earendil-works/pi-tui@0.84.2 ships TuiAltScreen — an alternate-screen mode with an application-owned, scrollable viewport, mouse-wheel handling, application-owned text selection with a clipboard hook, transcript search, and OSC 8 hyperlinks. TuiMode is already "regular" | "fullscreen" as a first-class option; Maka's CLI just doesn't reference it yet. So an anchored composer is a mode switch inside the existing dependency, not renderer surgery or an upstream fork — I'd initially assumed the latter and was glad to be wrong.

What that leaves is the honest trade-off, now empirical rather than architectural:

• Selection and copy become application-owned. Upstream mitigates this with its own selection, search, and clipboard plumbing, but whether it feels like native terminal selection is something only real use can answer.
• The transcript leaves the terminal's scrollback. Scroll-up history becomes app-owned too, which changes behavior users may rely on today (e.g. scrolling past the session into earlier terminal history, or finding output after exit).
• Q4's "preserve reading position + unread indicator" becomes buildable app code rather than a rendering-model change — which is where I'd start if Maka tries the mode at all.

Given the release cadence and the new nightly channel, my suggestion would be: try fullscreen on nightly first, with Q1–Q4 as the evaluation checklist, rather than debating the interaction in the abstract or adding a permanent in-product toggle. If nightly feedback shows native selection is what CLI users actually miss, that answer is cheap to act on; if it shows reading-while-working is the bigger win, the mode is already there to stabilize.

(Drafted with AI assistance; pi-tui API claims verified against the installed 0.84.2 package.)

中文版本

感谢把取舍摆得这么清楚——先问选择、复制和 scrollback 会发生什么，正是这个问题该有的切入点。

有一个事实会改变这个讨论的成本结构：全屏路径在 Maka 锁定的 TUI 依赖里已经存在。 @earendil-works/pi-tui@0.84.2 自带 TuiAltScreen——alternate-screen 模式，应用自管、可滚动的 viewport，带滚轮处理、应用侧文本选择和剪贴板 hook、transcript 搜索和 OSC 8 链接。TuiMode 已经是一等的 "regular" | "fullscreen" 选项，只是 Maka 的 CLI 还没有引用它。所以固定 composer 是在现有依赖里切模式，不需要动渲染器或 fork 上游——我一开始以为是后者，很高兴被事实纠正。

这样一来，剩下的就是诚实的取舍，而且是实证问题而不是架构问题：

• 选择和复制变成应用自管。 上游用自己的 selection、search 和剪贴板管线来弥补，但手感是否像终端原生，只有真实使用能回答。
• transcript 离开终端的 scrollback。 向上滚动的历史也变成应用自管，这会改变用户今天可能在依赖的行为（比如滚过会话顶部进入更早的终端历史，或退出后还能找到输出）。
• Q4 的"保持阅读位置 + 未读指示"变成可写的应用代码，而不是渲染模型改动——如果 Maka 要试这个模式，我会从这里开始。

考虑到发布节奏和新落地的 nightly 通道，我的建议是：先在 nightly 上试 fullscreen，把 Q1–Q4 当作评估清单，而不是抽象地争论交互、或在产品里加永久开关。如果 nightly 反馈证明 CLI 用户真正离不开的是原生选择，这个结论执行起来很便宜；如果证明边工作边回读才是更大的收益，这个模式也已经在那里等着转正了。

（本评论由 AI 辅助起草；pi-tui API 的论断均已对照本地安装的 0.84.2 包核实。）

[me2seeks]

Agreed — a nightly-first experiment sounds like the right next step. We can track the scoped trial in an issue, focusing on the anchored composer, preserved reading position and unread indication, and selection/copy behavior before deciding whether it should become a stable default.