-
Notifications
You must be signed in to change notification settings - Fork 35
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
The AC system sometimes deletes too many characters when committing a completion. #3296
Comments
In terms of the referenced gist, Sublime Text is working as designed there: Given text in the buffer of "acd", and a completion "abcd", then pressing tab and selecting the "abcd" option will result in the buffer containing "abcd", and not "acdabcd". Now clearly that's not what the intention behind a The next build with have an experimental flag that can be specified per-command completion item to have Sublime Text not remove the prefix at all, in which case the plugin will be responsible for that (including removing any characters the user typed after the completion was queried) With regards to the specific issue raised in this issue, I can't really comment on that without knowing the specific |
Thanks for looking into that tricky edge case. I've added the I fully agree with language independed heuristics to be a dangerous way which might create more edge cases that it was possible to solve. Looking forward to the "experimental flag". |
The approach described at https://discordapp.com/channels/280102180189634562/645268178397560865/704081503004524666 sounds quite interesting after an birds eye on it. It would enable a plugin to reset the buffer to the state the completion request was sent to a lsp server. This would enable plugins to apply the
|
That's exactly what sublime.COMPLETION_FLAG_KEEP_PREFIX promises to do :) I'll quote here for people that don't (want to) use discord:
|
Honestly, more and more I agree with https://forum.sublimetext.com/t/discord-server-vs-officially-hosted-forum/50920 Discord is a black hole for information. A bad place to store information in. |
Description
This issue continues the discussion about ST removing too many characters before calling a command_completion which was started at discord and continued by the comments at https://gist.github.com/jskinner/4dfa6d86f848e1e1e583883507369b67#gistcomment-3270107
It intends to provide some examples which hopefully help to find a proper solution.
For some reason ST removes the leading
<
even though typing started behind. As it is not part of the response of a language-server it gets lost.Used plugins
LSP / st4000-exploration branch
LSP-lemmix
Used file
Steps to reproduce
Expected behavior
Sublime Text should not delete too many characters. It may provide some API to either leave the whole text replacement up to a commit or let a plugin provide syntax specific details which may help ST's AC system to decide what to remove. The latter one would mean to pass the textEdit ranges to ST.
By replacing the
label
byfilterText
- as discussed in the gist - the completions are applied as expected.Note: Whether
filterText
should be used astrigger
or which options would be possible to support thelabel
part should be discussed in a separate issue.Actual behavior
Let me provide another example in which the closing tag
</xs:>
is not completed as expected as ST deletes the leading<
which is not part of the textEdit range returned by the LemMinX server.LSP payload logs
Type the
:
characterCharacter
:
triggers completionsReceiving the following respons
Passing the following completion items to ST (EDIT: added 2020/04/27)
Sending text modification notification caused by commit_completion command.
Another example is by requesting completions with the caret not being placed at the end but in the middle of the incomplete tag.
Press
ctrl+space
to trigger completionsReceive the completions from the server
Passing the following completion items to ST (EDIT: added 2020/04/27)
Send text change notification after running commit_completion command
Environment
The text was updated successfully, but these errors were encountered: