Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CodeLens disappears/and reappears when auto-saving. #245

Closed
SteelPhase opened this issue Jan 15, 2018 · 11 comments
Closed

CodeLens disappears/and reappears when auto-saving. #245

SteelPhase opened this issue Jan 15, 2018 · 11 comments
Assignees
Labels
bug Something isn't working

Comments

@SteelPhase
Copy link

Is it possible to not remove the gitlens annotation above a function when the file is saved/saving.
This leads to a lot of jumping around as vscode autosaves after delay, and just doesn't look very nice.

Note: this was extremely visible when editing a readme.md file

  • GitLens Version: 7.5.2
  • VSCode Version: 1.19.2
  • OS Version: osx 10.12.6

Steps to Reproduce:

  1. set files.autoSave to afterDelay
  2. edit a file, and pause your typing long enough for vscode to autosave.
  3. repeat step two until you feel uncomfortable with the bouncing source code.

Git Code Lens

CodeLens annotations should disappear and reappear after auto save.

@SteelPhase
Copy link
Author

I think I Phrased this wrong. CodeLens annotation disappears when the file is being modified. The issue really is it appearing/disappearing after the a short delay due to file.autoSave being set to afterDelay saving after a short delay.

@brunolemos
Copy link

I just came here for the first time to open a very similar issue but more generic: Avoid all the "jumping" the occurs in all cases (every time you open a file, modify it, ...).

Gitlens could show an empty space while it doesn't yet have the information.

Notice how it jumps:
gif

@eamodio eamodio self-assigned this Jan 15, 2018
@eamodio eamodio added the bug Something isn't working label Jan 15, 2018
@eamodio eamodio added this to the Soon™ milestone Jan 15, 2018
@eamodio
Copy link
Member

eamodio commented Jan 15, 2018

@SteelPhase this is a bad regression in 7.5 -- this will be fixed in 7.5.3 which will be out shortly. Sorry about that!

@brunolemos unfortunately there is nothing GitLens can do about that -- that is the way vscode behaves when dealing with code lens -- it always discards and refreshes them on tab switch.

@eamodio
Copy link
Member

eamodio commented Jan 15, 2018

7.5.3 is out now. Please let me know if you are still experiencing any issues. And again sorry for the inconvenience!

@brunolemos
Copy link

@eamodio congrats on the speed of the fix & ship!

@TomasHubelbauer
Copy link

@eamodio I don't know the API but could you avoid the jumping by quickly resolving to empty strings so that CodeLens lines are immediately as tall as they will be with data and then just backfill the data? This is a hack and I don't think it should be done, but in theory it would work as long as there isn't some perceivably long intrinsic delay before the file is open and CodeLens is invoked which would stay there even if the initial load resolved immediately.

@eamodio
Copy link
Member

eamodio commented Jan 15, 2018

vscode delays even asking for code lens, until after the tab has been switched -- so it will show without code lens before it even asks for them. I would recommend opening an issue with vscode (although there probably is one already honestly) to make the code lens rendering behavior smoother.

@TomasHubelbauer
Copy link

Agreed this should be resolved in VS Code proper so all extensions can benefit from it, although I am not bothered by the current behavior and I expect there is a performance trade-off precursor to the decision to delay, so I'll leave this be. Thank you for explaining. :-)

@RedTailBullet
Copy link

So have anyone reported this to the VS Code team?

@eamodio
Copy link
Member

eamodio commented Jan 11, 2019

@RedTailBullet My guess is it has been reported many times, but I also highly doubt they will change the behavior. The current behavior allows them to decouple the loading of the code from any delays/overhead extensions might add. This allows them to keep the coding experience fast.

@eamodio eamodio removed this from the Soon™ milestone Jul 19, 2019
@github-actions
Copy link

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Nov 30, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

5 participants