You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hovering over a variable shows type information about the variable. However, if the source file has unsaved edits that moved the variable's declaration around, the help message is rendered incorrectly.
To Reproduce**
Write a module with this function in it and save it:
test(<<X:32>>) ->X+1.
Hovering over X in the X = 1 expression displays the tooltip X :: number().
Now insert a space in the previous line before X, but do not save the document:
test(<< X:32>>) ->X+1.
Hovering over X in the X = 1 expression now gives the tooltip :: number().
Expected behavior
Unsaved edits that only move the declaration around shouldn't impact the help message.
Actual behavior
It looks like the variable's name is taken from the same position where it was declared in the saved file, even though it may now be moved around. E.g. adding some space before a variable with a long name will chop off characters from the end of its name, and deleting white space from before the variable will chop off characters from the beginning of its name.
Interestingly, renaming the variable would display the type help with the correct variable name, and no compilation errors are reported until the file is saved. For example with this unsaved edit:
test(<<Y:32>>) ->X+1.
Context
ELP Version (output of elp version): elp 1.1.0+build-2024-04-29
Editor used: VS Code
The text was updated successfully, but these errors were encountered:
That's fine, the issue is that while the file is modified, the help texts take a wrong section of the file somehow. Which is strange, because as the last example of renaming the variable shows, the original, correct text is still available to elp.
Currently eqwalizer is loosely coupled to ELP, and we get type information by querying against a position. This is memoized, and only updated when eqwalizer processes the file again. We generate the hover string using the text at the location we stored, and this has now changed.
I suspect we may have to just put up with it until we have a tighter integration between ELP and eqwalizer, at some unspecified future point.
Describe the bug
Hovering over a variable shows type information about the variable. However, if the source file has unsaved edits that moved the variable's declaration around, the help message is rendered incorrectly.
To Reproduce**
Write a module with this function in it and save it:
Hovering over
X
in theX = 1
expression displays the tooltipX :: number()
.Now insert a space in the previous line before
X
, but do not save the document:Hovering over
X
in theX = 1
expression now gives the tooltip:: number()
.Expected behavior
Unsaved edits that only move the declaration around shouldn't impact the help message.
Actual behavior
It looks like the variable's name is taken from the same position where it was declared in the saved file, even though it may now be moved around. E.g. adding some space before a variable with a long name will chop off characters from the end of its name, and deleting white space from before the variable will chop off characters from the beginning of its name.
Interestingly, renaming the variable would display the type help with the correct variable name, and no compilation errors are reported until the file is saved. For example with this unsaved edit:
Context
elp version
):elp 1.1.0+build-2024-04-29
The text was updated successfully, but these errors were encountered: