Hey @joelim-work!

I am unsure about your intend behind removing the nav.height sync.
Was the removal meant to rely on :redraw for sync, and drawbox just slipped through?

I also noticed inside #2206 that you changed the behaviour of tcell.EventResize to now explicitly re-sync height and keep only volatile previews.
Should I use this as an orientation instead?

Thanks for finding this bug - about your questions:

I am unsure about your intend behind removing the nav.height sync.
Was the removal meant to rely on :redraw for sync, and drawbox just slipped through?

It was just me forgetting that the nav height is affected by the drawbox option.

I also noticed inside #2206 that you changed the behaviour of tcell.EventResize to now explicitly re-sync height and keep only volatile previews.

This is specific for preloading and for volatile previews, but if the preview cache is completely cleared each time there is a resize, then the preview will have to be preloaded (one script call) and then previewed (another script call). The preloading step is unnecessary for volatile previews since there is nothing in the cache to update (there is just a dummy entry marked as volatile), and the new dimensions is passed in the previewing step which is then used by ueberzug/kitty. Keeping the preloading step adds a small but still noticeable delay.

Now as for this PR, the above patch is probably fine as a quick bug fix, but a more complete fix would be to create a function in the nav object that handles changes to the preview window size. It should:

• Store the current width and height.
• Compare with the new width and height (width also matters as pointed out in Keep text previews after horizontal resize #2201 (comment)).
• If there is any change, then invalidate any non-volatile cached previews (text previews contain a limited amount of lines, and sixel previews are sized according to the preview dimensions). Note that volatile previews should still be invalidated if the file is changed, or if the application is reloaded.

Now as for this PR, the above patch is probably fine as a quick bug fix, but a more complete fix would be to create a function in the nav object that handles changes to the preview window size. It should:

Store the current width and height.
Compare with the new width and height (width also matters as pointed out in #2201 (comment)).
If there is any change, then invalidate any non-volatile cached previews (text previews contain a limited amount of lines, and sixel previews are sized according to the preview dimensions). Note that volatile previews should still be invalidated if the file is changed, or if the application is reloaded.

All right. I will merge this one then and wait with a proper fix till #2206 is merged.

That's OK, I did this in #2218