leanprover/lean4

Go to definition does not work at end of identifier

lovettchris opened this issue · 14 comments

Prerequisites

  • Put an X between the brackets on this line if you have done all of the following:
    • Checked that your issue isn't already filed.
    • Reduced the issue to a self-contained, reproducible test case.

Description

I have a little external math function called factorial and when I do goto definition with the cursor at the end of the word it does not work right.

image

Steps to Reproduce

  1. double click the word "factorial" to select the whole word
  2. press F12 to goto definition

Expected behavior: [What you expect to happen]
Should work and take my to my factorial function, but it only works if I move the cursor left 1 char so it is "inside" the word "factorial".

Actual behavior: [What actually happens]
Fails to find it.

Reproduces how often: [What percentage of the time does it reproduce?]
100%

Versions

commit 89ab3ca

Additional Information

Any additional information, configuration or data that might be necessary to reproduce the issue.

Kha commented

This is problematic in the presence of custom notation. Should ⟨factorial|⟩, where | is the cursor position, go to factorial or to the definition of the anonymous constructor? We could make it work only when not followed directly by another token though.

This is problematic in the presence of custom notation. Should ⟨factorial|⟩, where | is the cursor position, go to factorial or to the definition of the anonymous constructor? We could make it work only when not followed directly by another token though.

@Kha I think this is a good compromise.

This is problematic in the presence of custom notation. Should ⟨factorial|⟩, where | is the cursor position, go to factorial or to the definition of the anonymous constructor? We could make it work only when not followed directly by another token though.

This is already inconsistent in the current implementation (using VSCode). When typing ⟨factorial|⟩ (with the cursor at the |) VSCode will highlight the word factorial, while the hover at the same position will show the info for ⟨⟩.

Kha commented

Thanks, good to know. Alternatively we could always prefer identifiers over adjacent tokens.

For the use case of selecting a word with a double-click, this is a bit weird in VSCode. With ⟨a, b⟩, when double-clicking anywhere in b⟩, both tokens will be selected. Also for identifiers, the cursor will be on the right side of the selection, but in, for example, <|, the cursor will be placed on the left side of the selection.

This makes it difficult to think of a solution that will work in all cases.

Kha commented

Then maybe the current behavior isn't too bad since at least it is consistent. I don't think I've ever used go-to-definition with a selection to be honest (if your hand is already on the mouse, why not use Ctrl + click?).

Kha commented

Ah, I forgot about your comment that it is already inconsistent right now in VS Code. I would be okay with any of the comprise solutions or the current behavior at this point.

@Kha What is the plan for this issue? You made a suggestion above, Lars raised a new concern, then you said "maybe the current behavior isn't too bad". I don't have a preference here, I am happy to close it with "wontfix", or try to fix it.

Kha commented

I still don't really understand the original use case of selecting the identifier first, so I'm okay with closing.

The user scenario is you use "find" to find something then you want to press F12, but it doesn't work because find selects the whole word, leaving the caret at the end of the word. Can the LSP fix this internally by just subtracting 1 from the position if it is at the end of a word and there is a following whitespace?

The other thing that is funky is the the tooltip shows it was looking for "append" and that's very confusing now, because we all know Array.append exists:

image

Kha commented

Thanks for elaborating, that makes more sense. Is the use case still relevant now that we have workspace symbol search?

Customers will complain because the Lean implementation of goto definition is non-standard. I vote we should fix it before that happens.

I think Chris' user scenario is realistic, and I can reproduce it.
I am removing the "closing soon".

woot!