Null response for empty completion requests

[LucasBullen]

Request:

{
  "jsonrpc":"2.0",
  "id":"2",
  "method":"textDocument/completion",
  "params":{
    "textDocument":{
      "uri":"file:///home/lbullen/runtime-EclipseApplication/NewDotnetProject1/NewDotnetProject1.csproj"
    },
    "uri":"file:///home/lbullen/runtime-EclipseApplication/NewDotnetProject1/NewDotnetProject1.csproj",
    "position":{
      "line":0,
      "character":0
    }
  }
}

Response:

{
  "protocolVersion":"2.0",
  "id":"2",
  "result":null
}

Looking at the LSP for completion-requests, the expected response should be CompletionItem[] | CompletionList.

null is not accepted or else the protocol would look like the Goto Definition Request Protocol: Location | Location[] | null

[tintoy]

Ooh, that's interesting - my understanding was that null means "completions not supported here" (VSCode seems to show an empty completion list if I return CompletionItem[], but no list at all if I return null). That signature comparison does seem compelling though.

If I start always returning non-null here it would break my extension (since I have to rely on "silently" triggering completion sometimes; VSCode may ask for completions, but shows nothing since I return null).

FWIW, my LSP client implementation is perfectly happy either way:

https://github.com/tintoy/dotnet-language-client/blob/master/src/LSP.Client/Clients/TextDocumentClient.Completions.cs#L32

How about if I add a feature flag to return empty completion lists instead of null - would that be good enough?

[tintoy]

Ok - after starting the language service, you can now get the behaviour you want by sending it a "workspace/didChangeConfiguration" message
with params along the lines of:

{
    "settings": {
        "msbuildProjectTools": {
            "language": {
                "enable": true,
                "logLevel": "Information",
                "experimentalFeatures": [
                    "empty-completion-lists"
                ]
            }
        }
    }
}

BTW, the full settings schema is:

{
    "settings": {
        "msbuildProjectTools": {
            "language": {
                "enable": true,
                "disableHover": false,
                "logLevel": "Information",
                "seqLogging": {
                    "url": "http://localhost:5341/",
                    "apiKey": "KN3CFcqcWmsirb3ztL9g",
                    "logLevel": "Verbose"
                },
                "completionsFromProject": [
                    "Property",
                    "ItemType",
                    "ItemMetadata",
                    "Target",
                    "Task"
                ],
                "experimentalFeatures": [
                    "expressions",
                    "empty-completion-lists"
                ]
            },
            "nuget": {
                "newestVersionsFirst": true,
                "disablePrefetch": true
            }
        }
    }
}

[tintoy]

BTW, sorry for the slow response - I didn't get the notification until this morning, for some reason!

[LucasBullen]

Is there a possibility for the experimentalFeatures to be set within the initializationOptions of the initialize call? LSP4E does not support making workspace/didChangeConfiguration calls.

BTW, sorry for the very slow response, was busy with other tasks

[tintoy]

No problem :)
Let me do an experiment or 2 - will need to see the server-side parameter type. Should be doable, or at worst I could make it an environment variable. Will give it a go as soon as I get to work (an hour and a half)

[tintoy]

Ok, yep, looks like I can do it - give me a couple of minutes. Do you need a new package, or can you run from source?

[tintoy]

Basically, just pass something like the following JSON in InitializationOptions:

{
    "msbuildProjectTools": {
        "logging": {
            "level": "Information"
        },
        "nuget": {
            "newestVersionsFirst": true,
            "disablePrefetch": true
        },
        "experimentalFeatures": [
            "empty-completion-lists"
        ],
        "schemaVersion": 1
    }
}

[LucasBullen]

Perfect! That did it, no more errors on my end. We will need a new package if that is a possibility then we will be able to add your completion-suggestion work to aCute (Whoot!) and have the rest of the features functional once the initialization capabilities issue is solved.

[tintoy]

Woohoo! Ok, will put put out a new release sometime this morning then :)

[tintoy]

Ok, @LucasBullen, here you go - v0.2.15

[tintoy]

PS. Thanks for using this - it's great to see broader adoption :)

[tintoy]

BTW, not sure if you support snippet-style completions; if not, some types of completions (e.g. new elements) may not work correctly yet. Let me know if this is the case, and I can either offer a setting to turn off unsupported suggestion types (quick) or implement a fall-back to regular-style completions (may take a while, but definitely doable, although the UX is slightly less pleasant without snippet-style support we have no control over cursor positioning after inserting the completion).

[LucasBullen]

Thanks! Yes lsp4e has snippet-style completion support and the new cut works great.