Currently splitting implementation via new PRs - feat(ui): preserve buffers on toggle #229

jensenojs · 2026-02-03T10:01:36Z

Background

This PR improves UI toggle behavior by introducing ui.persist_state (default: true) and refining window and buffer lifecycle handling.

Goal: when toggling UI off and on, preserve user context (buffers and cursor or scroll intent) without breaking close semantics.

Behavior Changes

Add ui.persist_state (default true):
- toggle now hides windows and preserves buffers when enabled.
- when disabled, behavior remains full close (buffers are deleted).
Normalize window state semantics:
- visible: input or output window is currently visible
- hidden: windows are closed but restorable hidden buffers exist
- closed: no visible windows and no restorable hidden buffers
Fix toggle open-state detection:
- output-only view (input auto-hidden) is treated as visible (not closed).
Make get_window_state() read-only:
- remove cursor-saving side effects from getter.
Restore policy after hidden reopen:
- if user was following bottom before hide, allow sync-to-latest behavior on reopen;
- if user was reading in the middle, preserve reading position.
Explicit hidden-buffer lifecycle:
- stash / consume / clear hidden snapshot
- validity checks for restored buffers
Type and LSP cleanup:
- reduce false diagnostics while keeping gd navigation targeting real implementations.

Test Coverage

Added and updated behavior-focused tests:

tests/unit/persist_state_spec.lua
- config default and override
- preserve on hide plus reopen reuse
- closed, visible, hidden state transitions
- get_window_state() purity (no mutation)
- output-only visible semantics
- persist_state=false full-close path
tests/unit/core_spec.lua
- hidden restore render gating:
  - no forced full render when preserving reading position
  - full render allowed when previously at bottom

Reviewer Guide

Suggested review order:

lua/opencode/state.lua: state model plus hidden snapshot lifecycle
lua/opencode/ui/ui.lua: close and create window lifecycle split
lua/opencode/core.lua: reopen render gating behavior
lua/opencode/api.lua: toggle semantics plus getter purity
tests for behavior lock-in

Risks / Compatibility

Default behavior changes toward preservation (persist_state=true).
Compatibility path is preserved via persist_state=false.
Main risk area is state transitions (visible/hidden/closed), covered by regression tests above.

disrupted · 2026-02-03T11:50:24Z

great addition! this is so useful, imo it would make for a sensible default. there is still :Opencode close for when the user would want to actually close it

sudo-tee · 2026-02-03T13:29:25Z

This sems like a useful feature.

As I will have to maintain this in the future, I would like it if you add a couple of tests for this.

As well as updating the README file

Thanks a lot for the PR

lua/opencode/config.lua

lua/opencode/api.lua

jensenojs · 2026-02-04T07:50:57Z

Sorry, I found some more subtle issues.

I'm glad you reviewed so carefully, including that it should probably be the default behavior. I will resolve all the above issues as soon as possible.

Add `persist_state` configuration option (default: true) that preserves buffers and cursor positions when toggling the UI off. This enables faster restore and maintains scroll position across toggle operations.

jensenojs · 2026-02-05T19:16:52Z

I am quite satisfied with my local behavior, (my nvim configuration will switch when the position is both left and center, plus I want to retain the cursor position when toggling, so although the code is relatively complex, I also spent quite a while calibrating through actual testing. I might record a video hhh)

The overall code writing and cleanup were all done by kimi2.5. There may be some unnecessary comments or still overdesigned parts here. I will carefully review my PR tomorrow and clean up that junk (it's late night here now, I have to sleep). I pushed the code up first in case someone might want to try it out early. @sudo-tee @disrupted

update :

iShot_2026-02-06_14.55.30.mp4

disrupted · 2026-02-06T12:56:07Z

at 0:13 in the video it looks like the cursor jumped up a little when re-opening the output buffer. do you know why that's happening?

sudo-tee · 2026-02-06T13:03:09Z

Thanks for the PR,

I will play with it a little bit in the coming days as welle a redo a finale review.

jensenojs · 2026-02-06T13:55:42Z

at 0:13 in the video it looks like the cursor jumped up a little when re-opening the output buffer. do you know why that's happening?在视频的 0:13 处，重新打开 output buffer 时光标似乎稍微向上跳了一下。你知道这是为什么吗？

When the cursor bounces back from the editing window to the opencode output window, if it wasn't at the bottom before (for example, if I was looking at messages in the middle), I want it to reappear at the corresponding position.

Actually, it's not just the cursor jumping up; it seems to be one of my autojump commands that centers the entire window, although it does create a bit of visual noise.

jensenojs · 2026-02-08T08:15:35Z

Need a more detailed performance evaluation and bottleneck analysis (in progress)

sudo-tee · 2026-02-09T15:46:52Z

I played a little bit with it this morning,

It progressing great, I like that I don't have to wait for a full render if I toggle the panel.

I find one issue where if you move the cursor in the outpout window withoud scrolling and close/reopen, the cursor will be set at the bottom instead of restoring to the last position.

There is also some tests failiong in the branch.

jensenojs · 2026-02-09T17:07:47Z

I played a little bit with it this morning,

It progressing great, I like that I don't have to wait for a full render if I toggle the panel.

I find one issue where if you move the cursor in the outpout window withoud scrolling and close/reopen, the cursor will be set at the bottom instead of restoring to the last position.

There is also some tests failiong in the branch.

I'm sorry—I've actually been running local tests in my off hours these past few days. What you mentioned is a known issue to me, but at the same time there's a more serious problem: using end-to-end load testing I can reproduce a severe performance issue. Restoring a cached buffer requires reattaching the window and setting the filetype, which triggers Treesitter to reparse all existing content in full. That cost negates the benefits of avoiding re-rendering.

I can't come up with a complete, well-reasoned conclusion right now, and I don't want to treat this project with a restless attitude. I'll need to look through the code myself again tomorrow — I can't keep relying on GPT-5.3 and Kimi2.5.

At first I implemented this feature almost entirely by vibe coding; when reviewing the code I looked at the data structures and added a mock to create a performance comparison test, which deceptively showed a 40% performance improvement.

But when I later compared latency end-to-end in a real opencode session (looped 100 times, comparing mean and std), the results were terrible (I really should've picked up on this script from the start). I was able to identify some plausible issues, like duplicate subscriptions (possibly a legacy problem) or treesitter doing full parses that took too long... The final optimizations weren't particularly satisfying, and since I didn't have deeper control over the code during that time, it was pretty bad.

jensenojs · 2026-02-12T11:42:05Z

Performance testing details are as follows, along with my originally intended commit message:

Added the `persist_state` configuration option to allow buffer states to be maintained on close/switch for quick recovery. Includes the following improvements:

- Added the `ui.persist_state` configuration (default true) to control closing behavior
- Implemented a hide/restore mechanism that preserves cursor positions, scroll states, and window layouts
- Add new APIs such as `api.hide()` and `api.get_window_state()`
- Optimize the event manager by adding health checks and external message polling
- Add performance benchmarking scripts to demonstrate performance improvements from persistence
- Update documentation to include usage examples and three-state layout conversion solutions

However, this commit has too many changes. For maintainability, I'd like to split it into several smaller PRs. Is that possible? (I'll assume you've agreed (lol @sudo-tee

I found I don't like that visual noise either, so I also added an option to control whether this thing can be turned on. @disrupted

sudo-tee · 2026-02-12T11:59:37Z

If you are able to split in multiple PR . I will agree. It will be easier

sudo-tee · 2026-02-12T13:15:32Z

lua/opencode/ui/input_window.lua

    group = group,
    buffer = windows.input_buf,
    callback = function()
+      -- Save cursor position before leaving


If possible, I'd like to keep comments only for explaining complex snippet.

AI tends to add comments for abvious thinks like this.

sudo-tee

I left a couple of little comments to improve readability.

Some tests are still failing in ther branch

A part from this it seems good

sudo-tee · 2026-02-12T13:19:16Z

lua/opencode/ui/ui.lua

 function M.create_split_windows(input_buf, output_buf)
-  if state.windows then
-    M.close_windows(state.windows)
+  if state.windows and state.windows.input_win and vim.api.nvim_win_is_valid(state.windows.input_win) then


There is a function in each window module calles M.mounted().

You might want to leverage it instead, as it checks the same conditions as this

sudo-tee · 2026-02-12T13:22:13Z

lua/opencode/api.lua

+    return nil
+  end
+
+  local input_cursor = get_window_cursor(windows and windows.input_win)


you could simplify the nil checks with this

local input_cursor = get_window_cursor(windows and windows.input_win) or state.get_cursor_position('input') local output_cursor = get_window_cursor(windows and windows.output_win) or state.get_cursor_position('output')

sudo-tee · 2026-02-12T13:23:26Z

lua/opencode/api.lua

+  end
+
+  local windows_open = state.windows ~= nil
+    and (is_valid_win(state.windows.input_win) or is_valid_win(state.windows.output_win))


You could use both input_window.mounted() and input_window.mounted() here

jensenojs changed the title ~~feat(ui):only hide buffer when keep_buffers_on_toggle=true~~ feat(ui): preserve buffers on toggle Feb 3, 2026

jensenojs force-pushed the impr/dont-close-buffer-when-toggle branch from cf1203c to 6ab8fd6 Compare February 3, 2026 11:33

jensenojs mentioned this pull request Feb 3, 2026

Planned / In progress features #43

Open

15 tasks

sudo-tee reviewed Feb 3, 2026

View reviewed changes

lua/opencode/config.lua Outdated Show resolved Hide resolved

lua/opencode/api.lua Show resolved Hide resolved

feat(ui): add persist_state for preserving buffers on toggle

ec6711e

Add `persist_state` configuration option (default: true) that preserves buffers and cursor positions when toggling the UI off. This enables faster restore and maintains scroll position across toggle operations.

jensenojs force-pushed the impr/dont-close-buffer-when-toggle branch from 6ab8fd6 to ec6711e Compare February 5, 2026 19:06

clean code

43b5468

jensenojs requested a review from sudo-tee February 6, 2026 07:27

sudo-tee reviewed Feb 12, 2026

View reviewed changes

jensenojs changed the title ~~feat(ui): preserve buffers on toggle~~ Currently splitting implementation via new PRs - feat(ui): preserve buffers on toggle Feb 12, 2026

This was referenced Feb 12, 2026

fix(ui): use cursor position for scroll-intent tracking #265

Merged

feat(ui): add reference_picker_center_on_jump config #266

Closed

jensenojs marked this pull request as draft February 13, 2026 02:27

Currently splitting implementation via new PRs - feat(ui): preserve buffers on toggle #229

Are you sure you want to change the base?

Currently splitting implementation via new PRs - feat(ui): preserve buffers on toggle #229

Uh oh!

Conversation

jensenojs commented Feb 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Background

Behavior Changes

Test Coverage

Reviewer Guide

Risks / Compatibility

Uh oh!

disrupted commented Feb 3, 2026

Uh oh!

sudo-tee commented Feb 3, 2026

Uh oh!

Uh oh!

Uh oh!

jensenojs commented Feb 4, 2026

Uh oh!

jensenojs commented Feb 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

disrupted commented Feb 6, 2026

Uh oh!

sudo-tee commented Feb 6, 2026

Uh oh!

jensenojs commented Feb 6, 2026

Uh oh!

jensenojs commented Feb 8, 2026

Uh oh!

sudo-tee commented Feb 9, 2026

Uh oh!

jensenojs commented Feb 9, 2026

Uh oh!

jensenojs commented Feb 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

sudo-tee commented Feb 12, 2026

Uh oh!

sudo-tee Feb 12, 2026

Choose a reason for hiding this comment

Uh oh!

jensenojs Feb 12, 2026

Choose a reason for hiding this comment

Uh oh!

sudo-tee left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sudo-tee Feb 12, 2026

Choose a reason for hiding this comment

Uh oh!

sudo-tee Feb 12, 2026

Choose a reason for hiding this comment

Uh oh!

sudo-tee Feb 12, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

jensenojs commented Feb 3, 2026 •

edited

Loading

jensenojs commented Feb 5, 2026 •

edited

Loading

jensenojs commented Feb 12, 2026 •

edited

Loading

sudo-tee left a comment •

edited

Loading