uncommited lines issues (slow navigation, refresh issues)

[jyemeier]

Something I've noticed is that if I'm scrolling though a file that has not been committed yet, nvim wants to hang as it scrolls though the lines. Only really manifests if I'm rapidly scrolling line by line. I first noticed it when I was using a smooth scroller like karb94/neoscroll.nvim (which would scroll the pageDns and PageUps), but notice the behavior if I just hold down j/k in normal mode too. It's fine if the line is part of a commit, but if it's not part of a commit, the virtual text takes a second before it shows.

Almost like it has to search the whole tree of commit messages and realize there's no blame message before makes a decision on the line and move on. I haven't read the code, but I could see this being a potential cause.

Additionally, you have to GitBlameToggle to get it to refresh the blame messages on the file after you commit.

I might suggest the following:

• Allow the gitblame_delay directive to stop the processing of the gitblame message until after the delay
• Expose a GitBlameRefresh command, or auto refresh whenever there's a commit or something along those lines.

[1-800-jono]

I'm also having the same problem. Took me a while because I thought it was another plugin but realized this only happened on uncommited file. Disabling git-blame.nvim solved the issue 😢

[f-person]

Hey! Thanks for the report! I'll look into it when I have some time. This seems to be caused by recent changes on uncommitted messages. You can temporarily switch to b8a23393827a0478dbf606f5397c328895bd4f0e. I believe it should fix the behavior for now while I work on the solutions; I'll keep you updated ;)

[f-person]

Hey folks! I wanted to fix this but wasn't able to reproduce it. Do you have any example open-source repo/minimal setup where this happens?

[jyemeier]

Try the following. I was concerned that you couldn't reproduce it, so I tried it myself with the minimal configuration below, and yeah, I noticed that it was working fine.

So I tried some big examples in a sizable git project, and as I was working, I noticed my CPU fan had spun up, so i threw up an htop, put a big uncommitted file in the tree and started scrolling to the top/bottom and compared the CPU usage vs one that had been committed, and there was a large discrepancy.

Using the included config, if I just C-d and C-u (or just j/k) though a committed file, I use a good portion of a single CPU.

If I do the same through an uncommitted file, I use a good portion of all 16 cores, and the fans start to spin up.

init.vim

call plug#begin()

Plug 'f-person/git-blame.nvim'
Plug 'karb94/neoscroll.nvim'

call plug#end()

lua << LUALINE
require('neoscroll').setup({
    easing_function = "quadratic" -- Default easing function
    -- Set any other options as needed
})

local t = {}
-- Syntax: t[keys] = {function, {function arguments}}
-- Use the "sine" easing function
t['<C-u>'] = {'scroll', {'-vim.wo.scroll', 'true', '350', [['sine']]}}
t['<C-d>'] = {'scroll', { 'vim.wo.scroll', 'true', '350', [['sine']]}}
-- Use the "circular" easing function
t['<C-b>'] = {'scroll', {'-vim.api.nvim_win_get_height(0)', 'true', '500', [['circular']]}}
t['<C-f>'] = {'scroll', { 'vim.api.nvim_win_get_height(0)', 'true', '500', [['circular']]}}
-- Pass "nil" to disable the easing animation (constant scrolling speed)
t['<C-y>'] = {'scroll', {'-0.10', 'false', '100', nil}}
t['<C-e>'] = {'scroll', { '0.10', 'false', '100', nil}}
-- When no easing function is provided the default easing function (in this case "quadratic") will be used
t['zt']    = {'zt', {'300'}}
t['zz']    = {'zz', {'300'}}
t['zb']    = {'zb', {'300'}}

require('neoscroll.config').set_mappings(t)
LUALINE

[f-person]

Hey! I was recently able to randomly reproduce this with some huge file! I'll try to fix this soon-ish! :)

[jinzhongjia]

this is because plugin use CursorMoved event and no debounce, that will frequently emit to query git commit info