Does it still support delay?

[wanaiqing]

blame_delay is not working...

[Eliot00]

I removed delay option, because this plugin now calls git commands asynchronously

[wanaiqing]

@Eliot00 how can I enable delay currently?

[Eliot00]

This feature has been removed, I wonder why you need a delay?

wanaiqing @.***> 于2023年6月26日周一 17:18写道：

@Eliot00 https://github.com/Eliot00 how can I enable delay currently?

— Reply to this email directly, view it on GitHub https://github.com/Eliot00/git-lens.vim/issues/6#issuecomment-1607058556, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEMGGLG5GVUBKZ2HC2NL4CDXNFHXTANCNFSM6AAAAAAZTFSLCQ . You are receiving this because you were mentioned.Message ID: @.***>

[wanaiqing]

@Eliot00 I think blame with a delay should be a natural feature, otherwise it makes blame info looks like a part of source code.

[Eliot00]

Ok, I will find time to add this feature back, or you can create a PR :)

wanaiqing @.***> 于2023年6月26日周一 22:02写道：

@Eliot00 https://github.com/Eliot00 I think blame with a delay should be a natural feature, otherwise it makes blame info looks like a part of source code.

— Reply to this email directly, view it on GitHub https://github.com/Eliot00/git-lens.vim/issues/6#issuecomment-1607559632, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEMGGLDIZ2E2NE3DTJAPJBTXNGJAVANCNFSM6AAAAAAZTFSLCQ . You are receiving this because you were mentioned.Message ID: @.***>

[wanaiqing]

Waiting for its back

[Eliot00]

This branch support delay config again, not sure if everyone likes this feature, so don't merge it into the main branch for now.

[wanaiqing]

This branch support delay config again, not sure if everyone likes this feature, so don't merge it into the main branch for now.

Does it has an impact on other features?

[Eliot00]

Does it has an impact on other features?

Not sure for yet.

And btw how to switch to this branch in vim by plugin like Vim-plug?

According to https://github.com/junegunn/vim-plug#example

Plug 'Eliot00/git-lens.vim', { 'branch': 'delay' }

[wanaiqing]

It seems buggy once a buffer loaded... For examples: 1.for a short first line (blame info rendered twice) [some text Author · Date · Log Author · Date · Log] 2.for a long first line (blame wrapped) [this is a line that is long enough to touch the right. ] [ Author · Date · Log ]

[wanaiqing]

It seems buggy once a buffer loaded... For examples: 1.for a short first line (blame info rendered twice) [some text Author · Date · Log Author · Date · Log] 2.for a long first line (blame wrapped) [this is a line that is long enough to touch the right. ] [ Author · Date · Log ]

I think it's a combination.... And repeat may be more than twice...

[Eliot00]

Thanks for your feedback, already fixed. @wanaiqing

[wanaiqing]

@Eliot00 Great, thanks

[wanaiqing]

I think I have to reopen this... The repetition problem comes again, it may be not just an issue for initializing a buffer, I accidentally triggered it after the buffer loading but not sure what's the cause.

[Eliot00]

~Moving the cursor when the previous timer is about to execute will cause timer_stop to be too late to clean up~

The cursor moves too fast and asynchronously displays the old blame on a new line. @wanaiqing

line changed ->
timer stop ->
clear virtual text ->
set time out show -> after 500ms
                               -> async job started
line changed ->
timer stop ->
clear virtual text ->
                            -> async job finished, render old blame info in new line
time out new blame info

[Eliot00]

This problem is only caused by moving the cursor just when the asynchronous task is not completed

[wanaiqing]

This problem is only caused by moving the cursor just when the asynchronous task is not completed

Seems right.

[Eliot00]

Temporary solution: clean up virtual text again before asynchronous task rendering

[wanaiqing]

Take your time, I'll wait for it to be a sophisticated feature on main branch