[CoreyKaylor]

Fixes #14.

The problem

A winbar takes the top screen row of a window, which moves that window's text down one row.

• Per-window bars (LspSaga breadcrumbs): only the source panes get a bar, so the code sits one row below its number/connector gutters.
• Global winbar: every split gets one, so the cell gutters line up, but the Kitty canvas was placed at the connector window's top row, the bar row. That puts it one row above the code.

The fix

A global winbar can't be hidden on one window: an empty local value falls back to the global one. So instead of removing bars, DiffBandit keeps the bar row the same across the windows that must line up.

• When any pane shows a winbar, the gutters, overview strips and panes without one get a blank bar, using the gutter background. Your own bars, like breadcrumbs, stay as they are.
• The session, merge and folder views re-check whenever one of their windows is redrawn (a decoration provider's on_win, read-only, which schedules the realign). A bar a plugin sets later, even from inside its own autocmd where OptionSet doesn't fire, is picked up on the next redraw.
• The Kitty canvas now starts below the connector's winbar, and viewport heights count only the rows that show code (nvim_win_get_height includes the winbar row).
• With a global winbar, the one-row status headers grow to two rows (a blank bar above the header). Neovim forces this.

Testing

• Added a session spec (suite 16g) for a bar on one pane, a global bar, removing the bar, and a bar set or cleared from inside another autocmd after the first render, plus a Kitty spec for the canvas row and height under a winbar.
• nvim --headless -u tests/run.lua passes.

Please confirm

@tpodolak @linduxed, could you try this branch with your setup (LspSaga breadcrumbs / vim.opt.winbar = "%=%m %f%=", cells and Kitty renderers) and confirm the rows line up? With lazy.nvim:

{ "CoreyKaylor/diffbandit.nvim", branch = "winbar-alignment" }

linduxed: you can drop your autocmd that turns the winbar off.

[tpodolak]

Thanks for looking into that @CoreyKaylor. It works when winbar is rendered immediately(focus on right diff panel from the start)

but when left panel is selected initially(e.g switching files with [f) and then right one is focused, then we are back to the offset issue

offset.mp4

Basically when winbar is rendered once diff lines were generated the issue remains. I dont know TBH why lspsaga defers winbar rendering, maybe I am able to somehow force it to be rendered eagerly

[CoreyKaylor]

Thanks for the video @tpodolak, that pinned it down.

LspSaga sets the breadcrumbs from inside its own CursorMoved/BufEnter/symbol-update callbacks. Neovim doesn't fire OptionSet from inside another autocmd, and a winbar appearing doesn't fire WinResized or WinScrolled either. So when the bar showed up after the first render (focus moving to the right pane, ]f/[f), nothing told DiffBandit about it. It only worked when the bar existed before the layout check.

5fcdd26 hooks the check into redraws instead: showing a winbar always redraws its window, so the next redraw re-aligns the gutters no matter how the bar was set. I reproduced your flow (left pane focused first, then a BufEnter hook sets the bar on the right pane) with both the cells and Kitty renderers, and the panes, gutters and image now move down together.

You shouldn't need to make LspSaga render eagerly. Could you update the branch and try again?

[tpodolak]

Thanks. Works now as expected for both cases for cell rendering. For kitty(on ghosty), center gutter is offset though when right winbar is lazy loaded

it resets to normal once I scroll up and down though

[CoreyKaylor]

Thanks @tpodolak, glad cells is sorted. I reproduced the Kitty one in Ghostty.

The offset wasn't a whole row: it grew further down the screen, about half a row by line 15. DiffBandit was sending the right thing; when the lazy winbar takes a row, it sends a new image one row shorter. But Ghostty doesn't resize an image's existing virtual placement when the same image id is re-sent with a new cell grid. It keeps the old 35-row grid and stretches the 34-row image over it. Scrolling fixed it only because a later transmit happened to replace the placement.

7eb0b1e deletes the old image and placement before sending a different grid (same-grid repaints, like scrolling, still replace in place). With that, the change band and add wedges land on their rows in Ghostty after the bar loads lazily. This probably also fixes the same drift after resizing the terminal or a split.

Could you pull the branch once more?

[tpodolak]

Works fine now with both Kitty and cell rendering. Thanks

[CoreyKaylor]

Thanks for all the feedback.