Closed imjaroiswebdev closed 1 year ago
With current master, it reads tmux buffer on vim's startup. With this change, it reads tmux buffer on every BufReadPost
event. They are not the same behavior.
Besides, moving s:TmuxBuffer()
from startup time to BufReadPost
does not actually solve the performance issue. It moves the time consuming task out of the startup profile. If s:TmuxBuffer()
takes 1 second, the user will still need to wait 1 second before vim is usable.
@roxma You were right about my previous intention for introducing and improvement, so thank you, because with your explanation You made me understand better the issue.
Unfortunately, I couldn't solve it entirely, because I only could get rid of the system call for the case when the plugin is used on Neovim, since it has its Job Control feature which are very straight forward to use and understand, I made to implement a way to call Tmux last buffer asynchronously, but I couldn't achieve the same for Vim.
However based on what I researched, Vim has a similar feature called job_start
, which indeed has a similar signature to Neovim's jobstart, but the event handler works a bit different and to be honest VimScript isn't neither my strongest language nor my preferred, so I couldn't made to implement a fallback async handling of the Tmux Buffer form Vim. Maybe for another day 🤔
LGTM, Thanks for your PR
Partially address #6, because the improvement is only available if Neovim Job Control is supported.
Performance comparison
Without Neovim
jobstart
optimizationWith Neovim
jobstart
optimization