Closed adigitoleo closed 1 year ago
Based on a quick perusal of the code, I see the most obvious candidates for slow functions in update_highlight
and get_window_info
, both of which are called on WinEnter
via source_win_enter
. If I get time I may try to debug this further.
EDIT: After some more trials, this must be related to having g:minimap_git_colors
enabled. I don't experience the slowdowns with it disabled.
Aha, I believe the issues I'm observing depend on filetypes. The slowdown when switching windows is only really noticable when I'm switching to special buffers like an empty buffer from :new
, maybe because they don't have a filetype or something they are causing problems. Perhaps these should be excluded by default.
In general, opening new windows for the first time still remains quite slow though.
It appears that the video in your post is corrupt (at least that is the message github is giving me), so unfortunately I am unable to review it.
As for 1)
, I'm not entirely sure why :new
would cause a delay, but opening a new file/buffer generally comes with a hit because we need to generate and cache the minimap, which involves scanning each line and recording the length. There is a ticket (#160) to push this scan to a background process and then update the minimap when it's done which which should help the issue, but making that work across platforms + the vim/nvim differences in managing background processes makes that a large feature that unfortunately may never get done.
I am curious about 2)
, since the caching should limit the performance hit of re-entering a buffer. Is that the issue that was dependent on filetypes?
I'm not able to repro 3)
. Is that with a command like bp
/bn
, or is that when navigating a split?
I think the video could be very helpful, if it's not too much trouble could you attempt to post it again? Thanks!
I have updated the video which shows that swapping to a help
buffer is faster than swapping to an empty buffer and the highlight issue. I was navigating splits with :wincmd
, I suspect it is related to entering the window rather than entering the buffer. After playing around with a few other source trees I have seen that it isn't always easy to reproduce. Sometimes highlights work properly when leaving the help
split. For me, the most reproducible delay and highlight corruption comes from navigating to splits with empty buffers, e.g. :new
. Generally, I don't notice any delay unless the git diff for the file is fairly large (>500 lines).
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Check list
Environment info
Version info
Question / Problem and steps to reproduce
This is probably several problems, but they are all related to buffer switching or opening new splits.
:new
, or even:help
).:wincmd
.:edit
(or opening a popup window in neovim, which must somehow reset things).I tried disabling some of my more obvious plugins that could cause compatibility issues, like fugitive, ALE, or things that change highlights on events, but the issue seems to be with this plugin.
Screencapture below, without ALE or fugitive enabled.
minimap-nvim-slow.webm