[st3] Ingores buffer indentation setting while typing
mprobst opened this issue · comments
I'm using +2 ws for blocks, +4 ws for overlong lines for indentation.
In Sublime Text, whenever I press enter, semicolon, or a number of other characters, the editor re-indents my contents to be +4 relativ to the last block starter (but also case label etc).
Any idea what's going on? I tried changing the hard coded 'tab_size' value in the .py plugin, to no avail.
Great question. Right now, the server is hard-coded to format using +4 ws for indent. The plan is to add an editor configuration message so that the plug-in can read the setting and inform the server.
AFAIR currently language service supports only one value of indentation for the entire document. If this is a requirement we can certainly support different indentations for different places in document however for this I'll suggest to file an issue in the primary TypeScript issue tracker since these changes should be done in the language service itself.
Filed a suggestion to track the progress of this issue
Not sure I was clear enough. I'm not referring to the formatter, I actually mean the interaction in the editor itself. I.e. when I type in a TypeScript file:
if (foo)[enter]
I end up with four whitespace characters in the next line. Even though the buffer is set to 2 whitespace indentation. In a JavaScript file, also with 2 ws set, the same produces only two whitespace characters on the next line, which is what I'd like to happen.
I think I see what you mean. There are 2 problems:
- plug-in has a hardcoded value for indentation - this is something that can be fixed in the plug-in
- language service does not support different values for indentations. Current assumption: indent size is a single value and it is applied when parent syntactic element introduces nesting. This is something that should be addressed on the language service side in main repo
There are some server-side and some client-side settings that relate to this. On the server-side, the format code options in the language service is currently set to indent size 4. This is because there is not yet a configuration message for the editor to send the server. When we add the configuration message the Sublime plug-in will read the setting and send the correct indent size.
On the client side, the current default is for [enter] to execute command typescript_format_on_key. This inserts the key ([enter] in this case, so '\n') and then asks the TypeScript language service to format the line on which [enter] was typed and also to indent the next line. We are currently thinking about whether this should be the default or the normal Sublime auto indent. Let us know what you think.
If you would like to change the behavior to the current Sublime auto indent, then you can remove the relevant lines in the Default.sublime-keymap file in the TypeScript package. They are:
{
"keys": [ "enter" ],
"command": "typescript_format_on_key",
"args": { "key": "\n" },
"context": [
{ "key": "auto_complete_visible", "operator": "equal", "operand": false },
{ "key": "selector", "operator": "not_equal", "operand": "meta.scope.between-tag-pair" },
{ "key": "selection_empty", "operator": "equal", "operand": true, "match_all": true },
{ "key": "num_selections", "operator": "equal", "operand": 1},
{ "key": "selector", "operator": "equal", "operand": "source.ts" }
]
},
AND
{
"keys": [ "enter" ],
"command": "typescript_auto_indent_on_enter_between_curly_brackets",
"context": [
{ "key": "auto_complete_visible", "operator": "equal", "operand": false },
{ "key": "selection_empty", "operator": "equal", "operand": true },
{ "key": "preceding_text", "operator": "regex_contains", "operand": "{$" },
{ "key": "following_text", "operator": "regex_contains", "operand": "^}" }
]
},
The ';' and '}' keys will also use TypeScript formatting. To completely remove TypeScript formatting, remove the relevant lines for these keys from the Default.sublime-keymap file.
After that, indenting should just be normal Sublime indenting.
Thanks Steve, that (together with deactivating all the typescript_paste_and_format commands) fixes the indentation issue.
I'd have to try the formatting with a setting that matches my usual indentation style to compare, but usually I'm quite happy with the editors normal behaviour.
The plan is to add an editor configuration message so that the plug-in can read the setting and inform the server.
Perhaps : https://github.com/TypeStrong/atom-typescript/blob/master/docs/tsconfig.md#format
tsconfig.json is a useful place to put formatting information that the plug-in could read. If a team has multiple editors, they could standardize format options by putting them in tsconfig.json. Another team might just have a document that standardizes options and format code settings for each editor.
We will be having the server read compiler options out of the tsconfig.json, but not formatting options. The reason is that the editor may have its own way of configuring formatting options (including reading them from tsconfig.json or sublime-settings). Teams will need to agree on formatting options and make sure each of their editors has the appropriate settings or has a plug-in that reads settings from tsconfig.json or other cross-editor config file.
@mprobst can you please tell me what sublime settings you use to get +2ws on indent and +4ws on line wrap? I'm adding logic to pick up settings and inform the server and I want to make sure I catch all of them.
tsconfig.json is a useful place to put formatting information that the plug-in could read
Thanks. I called them formatCodeOptions : https://github.com/TypeStrong/atom-typescript/blob/master/docs/tsconfig.md#formatcodeoptions to match what the TSServer https://github.com/Microsoft/TypeScript/blame/master/src/server/editorServices.ts#L262 seems to be expecting (although its not used by TSServer). I am using it in Atom-TypeScript.
@steveluc if I just set my buffer to "Spaces: 2" in the bottom right drop down, I get the +2 behaviour. Sublime Text sadly doesn't do +4 ws indentation on overlong wrapped lines automatically. But once you indented the first wrapped line at +4, it sticks to the indentation of the current line as you continue to break lines.