Code lens "recent change" shows on every Python import statement that imports a Class or Function SymbolKind

[phillipdwright]

• GitLens Version: 8.2.4
• VSCode Version: 1.23.0
• OS Version: Windows 10 Version 1803

Steps to Reproduce:

1. Include Python import statements of the form from X import Y, where Y is a class or function. Eg.,

from unittest import TestCase
from unittest.mock import patch, Mock
from unittest import mock


class SampleTestCase(TestCase):
    def test_something(self):
        mock_patch = Mock(patch)
        self.assertTrue(isinstance(mock_patch, mock.Mock))

2. Observe that Code lens "recent change" annotations are listed above every import statement that imports a class or function.

62a7eaf removed these annotations for imports of the form import X or from X import Y, where Y is a SymbolKind.Module, but they remain when Y is any other SymbolKind. I know there are settings for disabling "recent change" Code lens annotations (gitlens.codeLens.recentChange.enabled) and for disabling Code lens annotations altogether for different SymbolKinds, but this removes annotations that would be helpful elsewhere in the file.

With added settings

  "gitlens.debug": true,
  "gitlens.codeLens.scopesByLanguage": [
    {
      "language": "python",
      "scopes": [
        "document",
        "containers",
        "blocks"
      ]
    }
  ]

the example above shows as follows:

Adding "symbolScopes": ["!Module", "!Function", "!Class"] to my settings would also remove helpful Code lens annotations on the class and function definitions in the file.

Would it be possible to have Python import statements be treated differently for purposes of Code lens and only have annotations show up for SymbolKind.File on those lines?

[phillipdwright]

Awesome product, by the way! I love it.

[eamodio]

Unfortunately right now I don't think there is much I can do to address this. Although once microsoft/vscode#34968 lands I might be in a better position to be able to address this issue depending on the data provided by the language service and how abstract it can be.

Thanks! 😄

[ryotat]

I also had this issue but updating to VS Code (1.24.1) and Gitlens (8.4.0) seem to have fixed the issue. Thanks!

[eamodio]

I'm not sure why this changed -- maybe the python language service changed at the same time. @phillipdwright are you seeing this fixed as well?

[eamodio]

Err. Nevermind, this was fixed as part of #331

[fgs-pwright]

I don't believe this is resolved. #331 fixes this for imports of the form import X or from X import Y, where Y is a SymbolKind.Module. But the "recent change" annotations remain when Y is any other SymbolKind. In particular, I still see this issue for imports of the form from X import Y, where Y is a SymbolKind.Class or a SymbolKind.Function.

As a workaround, I have "gitlens.codeLens.recentChange.enabled": false in my User Settings, but I know I'm missing out on a helpful feature.

I have updated to VS Code 1.24.1 and GitLens 8.4.0.

[eamodio]

The only real option there is to use gitlens.codeLens.scopesByLanguage to pick and choose how you want each SymbolKind to behave.

Maybe once microsoft/vscode#34968 lands and the language services provide more information, I can detect that those symbols are within an import and then suppress them

[DJMcNab]

microsoft/vscode#34968 has landed, but it doesn't seem to give what we would need (unless I'm misunderstanding something).

I came to this issue because of a similar issue with @matklad's rust-analyzer, where there is recent changes for every simple mod statement, which doesn't seem right:

[eamodio]

microsoft/vscode#34968 didn't expose any more information to GitLens, but microsoft/vscode#57984 fixed that (which will be released when the vscode 1.28 ships).

I have also made some changes in the next release of GitLens, to stop adding the authorship codelens unless the symbol spans more than 1 line -- which should help with this issue as well.

[DJMcNab]

Yeah - that change to stop one line recent changes is a good thing - that looks like it should fix it. Sorry to have bothered you!

[eamodio]

No bother at all -- your post prompted me to add the single line change! 😄

[eamodio]

I'm going to close this, as I believe this has been addressed now.

[github-actions]

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.