Sitelet https://github.com/dlyongemallo/diffview-plus.nvim/pull/323
Skip to content

fix(file_history): keep collapsed entries folded when highlighting a file row - #323

Draft
jensenojs wants to merge 1 commit into
dlyongemallo:mainfrom
jensenojs:fix/file-history-fold-preservation
Draft

jensenojs wants to merge 1 commit into
dlyongemallo:mainfrom
jensenojs:fix/file-history-fold-preservation

Conversation

@jensenojs

Copy link
Copy Markdown

Problem

In the file history panel, highlight_item expands a collapsed commit entry just to land the cursor on one of its file rows:

if entry.folded then
    entry.folded = false
    self:render()
    self:redraw()
end
target_row = comp_struct.comp.lstart + i + 1

This makes any navigation that calls highlight_item (e.g. select_next_entry via <tab>, and the layout-swap rebuild path open() -> highlight_item when jumping between commits of different layouts, such as M -> A) silently re-expand entries the user explicitly collapsed with h.

Expected

Collapsing and expanding are explicit user actions (l / h). Cursor placement must not change fold state. This is also what _restore_state already guarantees on history rebuilds (update_entries), so the two rebuild paths now behave consistently.

Fix

Park the cursor on the entry row instead of expanding the entry:

if self.single_file or entry.folded then
    target_row = comp_struct.comp.lstart + 1
else
    target_row = comp_struct.comp.lstart + i + 1
end

Note on behaviour direction

The diff-view file panel's highlight_file deliberately expands collapsed directories to keep the active file visible. This change takes the opposite stance for the history panel: fold state is preserved on cursor placement, consistent with _restore_state. Happy to gate this behind a config option instead if that is preferred.

Tests

Added three cases to file_history_render_spec.lua:

  • a folded entry is not expanded; the cursor parks on the entry row
  • an expanded entry still lands on the file row (no regression)
  • single_file behaviour unchanged

make test on file_history_render_spec.lua and panel_spec.lua passes; stylua --check (2.4.1 luajit) clean; make type-check reports no new diagnostics (the 6 pre-existing deprecated warnings in path.lua/ui/panel.lua are unrelated).

…file row

highlight_item expanded a collapsed entry just to land the cursor on its
file row. Cursor placement must not change fold state: expanding and
collapsing are explicit user actions (l / h). Park the cursor on the
entry row instead, consistent with the fold preservation _restore_state
applies on history rebuilds.

This also fixes the layout-swap path: rebuilding the panel window (e.g.
jumping between M and A commits) called open() -> highlight_item, which
re-expanded entries the user had collapsed.

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Copilot review overview

🟡 Changes recommended

The global API stub needs exception-safe cleanup to prevent cascading test failures.

Get a fresh assessment by requesting another Copilot review.

Review effort: Balanced
Findings: 1 Medium severity

Open (1)
What changed in this PR

Preserves file-history fold state when highlighting files.

Changes:

  • Parks the cursor on collapsed entry rows without expanding them.
  • Adds coverage for folded, expanded, and single-file behavior.
File Description
file_history_panel.lua Preserves folds during highlighting.
file_history_render_spec.lua Adds regression tests.

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

Comment on lines +878 to +882
local orig = vim.api.nvim_win_set_cursor
vim.api.nvim_win_set_cursor = function(win, pos)
calls[#calls + 1] = { win = win, pos = pos }
end
panel._restore_cursor_patch = function()
@dlyongemallo

Copy link
Copy Markdown
Owner

I have to think more about this. It's a behavioural change, and I'm not sure that all users would find it intuitive. The current behaviour is that ]c / [c landing in a folded entry silently unfolded it, but with this change, the user now has to press l to see the files. That seems like it would break a common workflow?

This affects select_next_commit, select_prev_commit, select_first_entry, select_next_entry, next_entry_in_commit, prev_entry_in_commit, in addition to the layout-swap in open, select_next_entry and select_prev_entry.

@jensenojs

jensenojs commented Sep 22, 2026 •

Copy link
Copy Markdown
Author

Sorry, I need a couple more days to look into this. I didn’t mean to ignore you. I've just been a little busy.

@jensenojs
jensenojs marked this pull request as draft October 2, 2026 03:13
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.

3 participants