luukvbaal

> The only method that I can think of that maintains the cmdpreview state across redraws would be to re-invoke the associated preview callback when appropriate. Is this the proper...

I don't see a reason why the cmdpreview buffer in this approach can't still contain only the visible lines. The point is just to keep that window around until cmdpreview...

Well yes but like I said the resize issue is separate from replacing the ephemeral window with a persistent one, and is already present in the status quo. If anything...

I don't quite follow what you mean with "lazily applying the substitution preview". I think the command should (and currently does) just execute on the entire preview buffer. What is...

> It doesn't. The :substitute preview callback (AFAIK the only builtin cmdpreview callback) specifically only applies changes to lines that are visible in the viewport at the time of its...

I agree it makes more sense inside the `flush` guard. Don't remember why I placed it outside tbh, can reconsider the specific use case if this was ext_ui driven and...

Altough with this change status components may not be flushed to the screen then with `flush == false` which may be unexpected? I think that's why I placed it outside...

Yeah fixing the underlying issue seems necessary regardless. The following patch seems to prevent all flickering from #28667 and #28668. Patch 1 that resulted in some test failures ```diff diff...

Fine with me, but can anyone acknowledge why the treesitter highlighter should or shouldn't `flush`? As I see it this adds in a `ui_flush()` that only improves responsiveness as soon...

Upon reconsideration I'm fine with it if it's necessary for 0.10(although I think #28676 also fixes the problem this PR aims to fix), but I still believe the user doesn't...