Lsp: ST's "Revert" (F5) command makes server malfunctional

Created on 4 May 2020  Â·  4Comments  Â·  Source: sublimelsp/LSP

Problem

Tested servers: lsp-intelephense, pyls

After pressing F5 (the revert command), the server thinks the file is empty. Hence it returns None to any request after that.

When pressing F5, there seems to be a moment the view is empty. Maybe this is the cause?

LSP Log

:: <-  lsp-intelephense textDocument/publishDiagnostics: {'diagnostics': [{'message': "Expected type 'array'. Found 'string'.", 'code': 1006, 'severity': 1, 'range': {'end': {'character': 22, 'line': 28}, 'start': {'character': 14, 'line': 28}}, 'source': 'intelephense'}, {'message': "Expected type 'array'. Found 'string'.", 'code': 1006, 'severity': 1, 'range': {'end': {'character': 18, 'line': 30}, 'start': {'character': 14, 'line': 30}}, 'source': 'intelephense'}], 'uri': 'file:///E:/_Test/php/src/test.php'}
:: --> lsp-intelephense textDocument/hover(2): {'position': {'character': 5, 'line': 28}, 'textDocument': {'uri': 'file:///E:/_Test/php/src/test.php'}}
:: <<< lsp-intelephense 2: {'range': {'end': {'character': 7, 'line': 28}, 'start': {'character': 0, 'line': 28}}, 'contents': {'value': '__implode__\n\nJoin array elements with a string\n\n```php\n<?php\nfunction implode($glue = "", array $pieces) { }\n```\n\n_@param_ `string $glue`  \n\\[optional\\]\n\nDefaults to an empty string. This is not the preferred usage of implode as glue would be the second parameter and thus, the bad prototype would be used.\n\n_@param_ `array $pieces` — The array of strings to implode.\n\n_@return_ `string`  \na string containing a string representation of all the array elements in the same order, with the glue string between each element.\n\n_@link_ https://php.net/manual/en/function.implode.php', 'kind': 'markdown'}}

// now press F5, `489` is exactly the file length.
::  -> lsp-intelephense textDocument/didChange: {'contentChanges': [{'text': '', 'range': {'end': {'character': 0, 'line': 31}, 'start': {'character': 0, 'line': 0}}, 'rangeLength': 489}, {'text': '', 'range': {'end': {'character': 0, 'line': 0}, 'start': {'character': 0, 'line': 0}}, 'rangeLength': 0}], 'textDocument': {'version': 1, 'uri': 'file:///E:/_Test/php/src/test.php'}}
:: <-  lsp-intelephense textDocument/publishDiagnostics: {'diagnostics': [], 'uri': 'file:///E:/_Test/php/src/test.php', 'isClear': True}
:: --> lsp-intelephense textDocument/hover(3): {'position': {'character': 2, 'line': 29}, 'textDocument': {'uri': 'file:///E:/_Test/php/src/test.php'}}
:: <<< lsp-intelephense 3: None
:: --> lsp-intelephense textDocument/hover(4): {'position': {'character': 3, 'line': 27}, 'textDocument': {'uri': 'file:///E:/_Test/php/src/test.php'}}
:: <<< lsp-intelephense 4: None

Environments

  • OS: Win7 x64
  • ST: 4073
  • LSP: st4000-exploration branch (specifically, b002f549db66da76da85b99e30dde41638cdc300)

...

https://discordapp.com/channels/280102180189634562/645268178397560865/706793662897717248

rwols Today 17:05
Ah yeah the revert command removes everything but puts nothing back, at least from the POV of on_text_changed
sublime issue

Most helpful comment

I believe we could but we could also wait until it's fixed in ST so that we can remove the workaround.

All 4 comments

Looks like we send didChange notification that content was removed but there is no notification where content is inserted back.

{
  "contentChanges": [
    {
      "text": "",
      "range": {
        "end": {
          "character": 0,
          "line": 31
        },
        "start": {
          "character": 0,
          "line": 0
        }
      },
      "rangeLength": 489
    },
    {
      "text": "",
      "range": {
        "end": {
          "character": 0,
          "line": 0
        },
        "start": {
          "character": 0,
          "line": 0
        }
      },
      "rangeLength": 0
    }
  ],
  "textDocument": {
    "version": 1,
    "uri": "file:///E:/_Test/php/src/test.php"
  }
}

I think this was fixed with https://github.com/sublimelsp/LSP/pull/1097. Can this be closed?

I believe we could but we could also wait until it's fixed in ST so that we can remove the workaround.

I guess this can be closed now as of the latest LSP 1.0.7 / ST 4081?

Was this page helpful?
0 / 5 - 0 ratings

Related issues

JonasPf picture JonasPf  Â·  6Comments

chenglou picture chenglou  Â·  4Comments

ayoub-benali picture ayoub-benali  Â·  3Comments

brainplot picture brainplot  Â·  3Comments

evandrocoan picture evandrocoan  Â·  7Comments