Open charbelnicolas opened 5 months ago
I could be wrong, but based on some debugging I did some time ago, I think this is just how neovim operates when you open a new tab (i.e. it more or less functions similarly to :split
, except instead of copying the current win to a new win it copies the current tab to a new tab). Only after that (and after a redraw cycle apparently) does it change the windows of the new tab. So idk if there's a workaround or not (you'd probably need a way to open a new tab and configure it without entering it yet) and this is ultimately an issue with neovim (unless this plugin is the one forcing the aforementioned redraw).
I could be wrong, but based on some debugging I did some time ago, I think this is just how neovim operates when you open a new tab (i.e. it more or less functions similarly to
:split
, except instead of copying the current win to a new win it copies the current tab to a new tab). Only after that (and after a redraw cycle apparently) does it change the windows of the new tab. So idk if there's a workaround or not (you'd probably need a way to open a new tab and configure it without entering it yet) and this is ultimately an issue with neovim (unless this plugin is the one forcing the aforementioned redraw).
It could be... but how come the very first time it opens it does so cleanly without flashing anything?
~On my end it does the same thing the first time~ (or maybe not, maybe I just have bad eyes lol). But you're right, doing A and B with tabnew existingfile
, it seems that that doesn't have the flashing issue.
Maybe it's just from setting up the multiple windows after tabnew
? Or maybe the plugin is simply forcing a :redraw
(or, vim.schedule()
, async func) somewhere upon loading a new tab (and then updating the view after), that can create flashes.
There's actually a vim option to slow down redrawing I believe (for debugging). That might help give some answers/insight into what is going on to cause the flashes. Check out 'redrawdebug'
or 'lazyredraw'
.
So today I was going through the diffview code and I noticed that there were these FIXME
comments added after a refactor, so maybe they have something to do with it:
Hopefully it will get fixed in the future ;)
Hello @sindrets, I know working for free isn't fun, so please let me know if there is a one time sponsored payment I could make to fix this bug. I'm willing to spend up to $30 USD (no offense).
Description
I don't think I had noticed this in the previous months but now it's really hard to unsee. When opening a Diffview window (either DiffviewOpen or DiffviewFileHistory), unless it's the very first time opening it (it is possible then to fix and not flash a buffer!), it will flash the current focused window buffer on both Diffview editor windows.
Let's assume I have this window open:
After opening a Diffview window once, If I open Diffview again, every consequent DiffviewOpen will flash the current focused buffer first instead of showing the right contents.
And it is then that the correct buffer will show:
Here's a video:
https://drive.google.com/file/d/11-etwvc3RU5f5bLy2_YVllcG0jYz5CY3/view?usp=sharing
Expected behavior
I expect to transition correctly into the desired Diffview output instead of seeing a flash of my current focused window buffer.
Actual behavior
I see a flash of buffer content that is not correct.
Steps to reproduce
Health check
Log info
Relevant info from
``` ############################ ### PUT LOG CONTENT HERE ### ############################ ```:DiffviewLog
Neovim version
Operating system and version
Linux 6.9.3-arch1-1 x86_64 GNU/Linux
Minimal config