mrjones2014
Reduce number of reloads while resizing?
I found that a lot is going on during resizing with smart-splits. Even when using a decent machine, this often produces a latency compared to regular resizing .
An example that makes it very visible is when using a statusline line like galaxyline. The statusline flashes between active and inactive mode on every resize step.
Another example is when opening two splits from different working directories and additionally a file tree that adapts to the working directory of the active buffer like nvim-tree. Using smart splits, the file tree flashes between the working directories with every resize step.
Depending on the tree plugin, and it's configuration smart-splits behavior also changes visible directories.
Working on a decent machine this won't produce peaks in system workload or something. Still, performing multiple resize steps in a row using smart splits often has a recognizable latency compared to regular resizing. But for those working on a weaker system, those become pretty recognizable lags.
Is this much processing and switching between buffers necessary for the plugins to work? If are there any ideas or plans for further development you can share, maybe the community can help with some implementations.
I'm not sure how I can do it and still catch all the edge cases I'm handling.
Had it in the back of my mind that I opened this issue. Wanting to check back on it and implement some caching I've seen you have already implemented it. I guess it's as much resolved as it can get.
Gonna take the freedom to close this issue.
Today I learned that winnr('h')/winnr('j')/winnr('k')/winnr('l') can be used to determine if you're at an edge window so I should be able to compute edges in fewer steps using this.