search

mrjones2014 / smart-splits.nvim

🧠 Smart, seamless, directional navigation and resizing of Neovim + terminal multiplexer splits. Supports tmux, Wezterm, and Kitty. Think about splits in terms of "up/down/left/right".
MIT License
906 stars 38 forks source link

Reduce number of reloads while resizing? #25

Closed ttytm closed 1 year ago

ttytm commented 2 years ago

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.

mrjones2014 commented 2 years ago

I'm not sure how I can do it and still catch all the edge cases I'm handling.

ttytm commented 1 year ago

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.

mrjones2014 commented 1 year ago

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.