Skip to content
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.

Sign up for GitHub

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

Jump to bottom

textDocument/didChange interpretation #112

Closed
alanz opened this issue Aug 30, 2017 · 0 comments · Fixed by #113
Closed

textDocument/didChange interpretation #112

alanz opened this issue Aug 30, 2017 · 0 comments · Fixed by #113

Comments

@alanz
Copy link
Contributor

alanz commented Aug 30, 2017

At the moment we accumulate changes and send them once a timer triggers.

Each emacs onChange event is wrt to the document at the point when the change is made.

This means the order of application is important, and needs to be preserved.

However

According to microsoft/language-server-protocol#279, the changes in a single textDocument/didChange message should all be wrt the same document, and hence they need to be applied in reverse order.

So, to fix this we can either

  • Send one textDocument/didChange per emacs change, as it is reported; or
  • Adjust the edit locations so that they all refer to the original document, so they can be applied according to the specification.

The first option is simpler, and seems to be what happens in vscode. But, it means we potentially run diagnostics generation more frequently than required.
alanz added a commit to alanz/lsp-mode that referenced this issue Aug 30, 2017
@alanz
Send changes immediately instead of queueing them
63f21e1 
For incremental change mode, all the changes in a `textDocument/didChange`
message are interpreted as applying to the same version of a particular
document.

But each emacs change corresponds to the state of the document when the change
happens. So harmonise the expectations by sending each change in its own
message.

closes emacs-lsp#112
alanz added a commit to alanz/lsp-mode that referenced this issue Aug 30, 2017
@alanz
Send changes immediately instead of queueing them
3d230b7 
For incremental change mode, all the changes in a `textDocument/didChange`
message are interpreted as applying to the same version of a particular
document.

But each emacs change corresponds to the state of the document when the change
happens. So harmonise the expectations by sending each change in its own
message.

closes emacs-lsp#112
@alanz alanz mentioned this issue Aug 30, 2017
Merged
@alanz alanz mentioned this issue Jan 19, 2018
Closed
@alanz alanz mentioned this issue Dec 12, 2018
Closed
wkirschbaum pushed a commit to wkirschbaum/lsp-mode that referenced this issue Jun 1, 2021
@JakeBecker
Merge pull request emacs-lsp#112 from JakeBecker/issue-109
e06d7a7 
Avoid crashing main server process in code lens request when uri is n…
wkirschbaum pushed a commit to wkirschbaum/lsp-mode that referenced this issue Jun 1, 2021
@axelson
Update changelog for emacs-lsp#306 and vscode emacs-lsp#112
a02fc78
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Send changes immediately instead of queueing them alanz/lsp-mode
1 participant
@alanz