Is it possible to eliminate the flash of an unpadded buffer?

[gregorias]

Describe the problem

I have configured No Neck Pain to start on VimEnter. Even with this setting, the plugin adds padding only after a buffer and its window are loaded and displayed, e.g., when I do nvim SOME_FILE. This causes a visible flash of unpadded buffer, which, like flash of unstyled content), is unpleasant.

Describe the solution

I don’t know how to solve this, but I haven’t researched this. It would be nice if the pads could be calculated and added before the buffer is displayed.

Notes

Thank you so much for this plugin. I use it every day.

[shortcuts]

Hey, thanks for reporting and using the plugin :)

I currently rely on BufEnter which IIRC is one of the first event of the sequence when starting nvim, and the safest for everyone's need (e.g. if you have startup plugins like file explorers or dashboards).

Sadly most of the other events earlier in the loop (e.g. BufAdd or anything usually triggered before entering a buffer) are not available on vim startup, but I doubt they'd make humanly distinguishable changes anyway.

The only solution I see is to introduce a fast opt-in mode that is less safe but reduces the UI shift as much as possible. Would you mind trying it out from the branch?

I have configured No Neck Pain to start on VimEnter.

Just wondering, are you running your own autocmd or are you using the provided enableOnVimEnter option?

[gregorias]

BufEnter might be fine, because it still happens before UIEnter. I don’t think doing things sooner should be the issue (although I’m not familiar with how NNP works).

Food for thought: I’m suspicious of any solution that relies on being “fast,” because that suggests to me that it’s asynchronous. When I start Neovim in a vsplit mode with nvim -O A B C, Neovim opens all three buffers in evenly divided windows. There’s no asynchronous adjustment of window width, the split setup happens before the windows are drawn.
Perhaps NNP could take a look on how window splits work and do something similar?

The only solution I see is to introduce a fast opt-in mode that is less safe but reduces the UI shift as much as possible. Would you mind trying it out from the branch?

I’ve tried it out, it doesn’t fix the flicker.

Just wondering, are you running your own autocmd or are you using the provided enableOnVimEnter option?

For the testing above, I did. I sort of use enableOnVimEnter, but I have a custom setup that suppresses NNP when I have the dashboard on. I found weird layout behavior if I do stuff like open a quickfix window while nvim-dashboard is on.

[gregorias]

So I found that the source of the issue is the debouncing logic. I’ve fixed the flicker by skipping debouncing like so:

vim.api.nvim_create_autocmd({ "VimEnter" }, {
  pattern = "*",
  once = true,
  callback = function()
    require("no-neck-pain.main").enable("")
  end,
})

I think that no debouncing should be the default for start-up. Debouncing only causes the layout shift.

[shortcuts]

sorry for the delay I took some time off with the holidays, and thanks for following up with more investigation!!

BufEnter might be fine, because it still happens before UIEnter. I don’t think doing things sooner should be the issue (although I’m not familiar with how NNP works).

Food for thought: I’m suspicious of any solution that relies on being “fast,” because that suggests to me that it’s asynchronous. When I start Neovim in a vsplit mode with nvim -O A B C, Neovim opens all three buffers in evenly divided windows. There’s no asynchronous adjustment of window width, the split setup happens before the windows are drawn. Perhaps NNP could take a look on how window splits work and do something similar?

The thing is that not every dashboard/file browser etc. are implemented the same way, so I had to introduce some debouncing logic to prevent race conditions with other plugins. e.g. with oil.nvim it happens that the cursor got stuck in a side buffer without the debounce, because oil highjack the first valid window encountered, so if nnp creates one first, it messes up everything.

So I found that the source of the issue is the debouncing logic. I’ve fixed the flicker by skipping debouncing like so:

Ah that make sense, I guess it messes up with the event loop even with the 2ms default that we have, even with 0 it still creates the flicker. I need to do some more tests with the other integrations

[shortcuts]

update: I can confirm that this breaks the oil.nvim support, you end up with one of the 3 following scenarios due to race conditions:

unable to determine the window:

oil isn't triggered for some reason:

focus on the wrong window:

---

I can dig a bit to see if we can mitigate that but I doubt it, it might not be a sane default, however it can be opt-in

[shortcuts]

I've removed the debounce in #429 in case you'd like to experiment

[shortcuts]

oh I think I found a sane fast implementation that could be the default, it debounces only the part that recomputes the width and cursor position, so there's no flickering and it prevents the above oil bugs

I need to do more tests with other integrations