FormattingOptions should match the LSP's

[giltho]

Hi!

The LSP describes more formatting features than what VSCode can provide. Therefore, the LanguageClient can only handle part of the protocol's available parameters (see the related issue : microsoft/vscode-languageserver-node#617)

In particular, the FormattingOptions interface should contain more fields:

export interface FormattingOptions {
	/**
	 * Size of a tab in spaces.
	 */
	tabSize: number;
	/**
	 * Prefer spaces over tabs.
	 */
	insertSpaces: boolean;
	/**
	 * Trim trailing whitespace on a line.
	 */
	trimTrailingWhitespace?: boolean;
	/**
	 * Insert a newline character at the end of the file if one does not exist.
	 */
	insertFinalNewline?: boolean;
	/**
	 * Trim all newlines after the final newline at the end of the file.
	 */
	trimFinalNewlines?: boolean;
}

If there is also a way to pass more options (the [key: string]: boolean | number | string; part of the protocol) it would be extra nice, but I don't know if that should be done by vscode of handled directly by the language-client lib.

Also, since we're here, maybe this type and the protocol's should be extended with a lineWidth parameter which is common to a lot of formatters and we need in the case of the OCaml LSP (see issues on ocaml-lsp and on the ocaml-vscode plugin)

[jrieken]

I don't think that's needed, all those trimming features are built into VS Code itselves and no formatter is needed for that. We have a "catch-all" signature for various different options:

vscode/src/vs/vscode.d.ts

Lines 3417 to 3420 in af3c79e

	/**
	* Signature for further properties.
	*/
	[key: string]: boolean | number | string;

I honestly think that enough, because it kinda matches what vs code offers by default and other options can be defined (and read) by extensions themselves

[giltho]

Hi ! Thank you for your answer :)

There is a mismatch between protocol usage and vscode itself.
When writing a language server, one expects to receive formatting options through DocumentFormattingParams.options : FormattingOptions.

And although the interface exposes more, VSCode only passes part of that information to the provider here, because modes.FormattingOptions is a more restricted type than the one exposed in vscode.d.ts.

Not being able to use these parameters creates a discrepancy between vscode and other editors which may pass the information there.

It would be ok for vscode not to implement and pass them, but then the protocol should probably also deprecate these parameters and ask the server implementers to go lookup in the workspace configuration for these options.

[jrieken]

And although the interface exposes more, VSCode only passes part of that information to the provider here, because modes.FormattingOptions is a more restricted type than the one exposed in vscode.d.ts.

This isn't a problem of VS Code but the LSP client library. It is free to add whatever option it wants. fyi @dbaeumer

[dbaeumer]

In LSP we added theses options for editor which don't have built in support for this and need to depend on a formatter.