adjustments to additionalTextEdits are slightly off when on different line (when applying a proposal)

[martinlippert]

I have content-assist proposals with additionalTextEdits that affected pieces of the document behind the current cursor position. But it looks like the position of the additionalTextEdits, when applied, is not adjusted with regards to a potential changed document.

Here is the exact case:

• I type a character, the client asks the language server for completion proposals
• the completion proposals contain additionalTextEdits that are calculated based on the document state when the completion proposals where requested
• now the user continues typing and the client filters the list of proposals (based on the changed prefix), the client does not ask the server for new completion proposals
• now the client applies the completion proposal. The additionalTextEdits need to be adjusted with regards to the additional characters the user typed since the client asked the server for the completion proposals.

Please note that the extra call to the server to resolve completion proposals doesn't help here, because this resolve call gets called when the user scrolls to the completion proposal in the UI (the proposals popup), it does not happen after the user typed additional characters.

[martinlippert]

Another note: This is, of course, only necessary if the additionalTextEdits have a start offset that is greater than the cursor position (at the time of requesting the completion proposals).

AdditionalTextEdits that appear before the current cursor position (e.g. automated insertion of new import statements) work nicely, of course.

[martinlippert]

Actually, I debugged through the code a bit and it looks like there is code already to adjust the AdditionalTextEdits - and it looks like this adjustment is actually the problem... :-)

The additional text edit contains a line number and a character number in that line. So as long as the additional text edit is on a different line than the completion happened, the adjustment does NOT need to happen - at least this is what is looks like to me.

[martinlippert]

@vrubezhny I saw you implemented the related code in 9915647c28a934d376f86ecdfcc58382441ff54f, do you remember the exact use case you had for this? Seems like I need to understand this in more detail

[mickaelistria]

Fixes with #897