Don't send textDocument/didSave unless server advertises support for it

[DanTup]

I think the comment about didSave being sent unconditionally in #114 is incorrect. In the spec the ServerCapabilities has:

/**
 * Defines how text documents are synced. Is either a detailed structure defining each notification or
 * for backwards compatibility the TextDocumentSyncKind number. If omitted it defaults to `TextDocumentSyncKind.None`.
 */
textDocumentSync?: TextDocumentSyncOptions | number;

My interpretation is that textDocument/didSave should not be sent if textDocumentSync is 1, 2 or an object with .save == true. In Dart we're sending an object (TextDocumentSyncOptions) with save set to false.

[natebosch]

The save field should be a SaveOptions instance, which has a single boolean field includeText.

My impression is that the didSave request should be sent unconditionally, but that the server can indicate whether it wants the text included.

We could only send didSave notifications if the save field is a non-null dict, regardless of the value of includeText, but I'm worried it would be breaking and I can't tell from the spec whether that would be correct.

[natebosch]

Here's an issue discussing this:
microsoft/language-server-protocol#288

I think what you want to do in the server is send a dict without the save key, and I can interpret the missing key as "don't send".

[DanTup]

Sorry, I made a mistake reading what we sent above where I mentioned a boolean (I read the willSave field). We are actually already not sending save:

new TextDocumentSyncOptions(
          true,
          TextDocumentSyncKind.Incremental,
          false,
          false,
          null,
        )

"textDocumentSync": {
	"openClose":  true,
	"change":  2,
	"willSave":  false,
	"willSaveWaitUntil": false
}

[natebosch]

Sounds good, this client doesn't support willSave so I'll see about disabling the didSave in the case where the save field is omitted.