Variable names consume the underline

[marimeireles]

Hey Jupyterlab-lsp folks!

Description

Using pyls-memestra I found a bug and I believe it's happening because of something wrong with juplab-lsb. Variable names are consuming the underline on the deprecated class/function.

Reproduce

You can see it happening here: https://mybinder.org/v2/gh/QuantStack/pyls-memestra/master?urlpath=/lab/tree/binder/default_decorator_example.ipynb

But here is a screenshot:

Any opinions on this? Have you seen this before?

Thanks a lot!

Related issue: QuantStack/pyls-memestra#25

[krassowski]

Thanks for reporting. Indeed I can reproduce this (on firefox for now). I will look into this.

The binder had some hiccup on on Chrome:

[krassowski]

If you need something ASAP you could pin your binder to the previous version (2.0.6) where the hover underlines were not showing up at all.

[marimeireles]

Thanks for this @krassowski, didn't know we had a chrome issue. Will investigate!

[krassowski]

The binder on Chrome started working after a third trial - just a hiccup apparently.

[krassowski]

Hi @marimeireles, I had a quick look and I think that this might be on your side:

SomeOldClass has 12 characters but the diagnostic (as shown above) specifies a range between 6th and 12th character - and we correctly only underline the first 6 characters.

Edit: In earlier version of this comment, I incorrectly mentioned SomeOldFunction where it should have been SomeOldClass

[marimeireles]

Ah yeah! It does look like something on my side.
That's right. I'm sorry for this!

[krassowski]

No worries, glad I could help! It looks that the err_range defionition, which currently is:

err_range = {
    'start': {'line': lineno - 1, 'character': colno},
    'end': {'line': lineno - 1, 'character': len(fname)},
}

should have been:

err_range = {
    'start': {'line': lineno - 1, 'character': colno},
    'end': {'line': lineno - 1, 'character': colno + len(fname)},  # <- change here
}

Hope it helps. Thanks for the mention of jupyterlab-lsp in the blog post btw!

[marimeireles]

You're welcome @krassowski, you're doing an amazing job here :)
Sorry for opening the issue without investigating it properly and thanks!

[bollwyvl]

awesome debugging, folks!

one of the things that will hopefully come out of the language server kernel proxy #278 is that we would be able to offer that part of the stack headless with a client for testing these kinds of things... some other "language server construction kits" have some utilities like this, but it might be useful for us to have in-package... it may make sense to land that in pygls and take that as an optional dependency... unless there's a lot of value in using it directly.