-
Notifications
You must be signed in to change notification settings - Fork 240
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
Autocomplete: Fix suggestion event over counting #649
Conversation
Thank you for the fix and sorry for the regression! |
const insertion = completion.insertText | ||
let j = 0 | ||
// eslint-disable-next-line @typescript-eslint/prefer-for-of | ||
for (let i = 0; i < insertion.length; i++) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we need to compare strings here symbol by symbol? Can we just insertion === suffix
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@vovakulikov VS Code is actually pretty advanced here and will diff the insertion with the text that is already at the range. It will render the completion as long as it is only additions to the text. These are clustered but it can be more than one cluster. Here's an example:
![Screenshot 2023-08-10 at 19 20 44](https://private-user-images.githubusercontent.com/458591/259822299-3c1c289e-0d99-4c94-824e-90bec3afc32b.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjE2MjA2MjksIm5iZiI6MTcyMTYyMDMyOSwicGF0aCI6Ii80NTg1OTEvMjU5ODIyMjk5LTNjMWMyODllLTBkOTktNGM5NC04MjRlLTkwYmVjM2FmYzMyYi5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjQwNzIyJTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI0MDcyMlQwMzUyMDlaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT0xODJjNjIzZGNiNTRiZmUyYmE5ZmNhNWFiNmJhM2UzNDE4YTljNTM5NjFkNzBhNDE1ZDk4ZjE1ZjUyYmU0Yzc4JlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCZhY3Rvcl9pZD0wJmtleV9pZD0wJnJlcG9faWQ9MCJ9.wd4_epsekX3XZoP-6AbW3RwU6FYKszcAmMraX26JfUM)
The suffix in this case is , ]
and the insertion is 2, 3]
. A simple string match won't work here, so I’m instead looping over the insertion to ensure it contains all characters from the suffix, in our case, it will find all 3 chars:
2, 3]
^^ ^
This PR fixes an issue that sometimes caused completion suggestion events to not fire correctly. The issue here was that we decided wether or not a completion is visible in the
getInlineCompletions
code that was now change to still yield completions.The yielding is fine, we have relied on these results to be used for the last candidate cache. However, this would also mean that we would store a log id that was deemed as not visible but that never reconsidered this condition. This meant that such a completion could become visible later and we would be able to accept it, even though it was never logged as suggested.
To fix this, we move this logic into the VS Code specific part (which conceptually makes more sense anyways since it's full of VS Code specific logic) and also test the visibility after every cache retrieval.
Test plan
I've added three conditions to test invariants that should not be possible. To test locally, I've added debugger break points into either of them and repeatedly triggered a bazillion of completions. After these changes, I don't seem to be able to trigger them anymore. I’m leaving some logs in there, though, so we can see if they happen on production.