This is an attempt to address issue #10339.
Background:
Currently, the `editor.tabSize` option does two things - it specifies the width of the tab character and it specifies how many columns to advance when the tab key is pressed. However, there is code in the wild that has a mix of spaces and tabs that expects these two values to be different.
These generally use and indent size of 2 or 4 and spaces are used for indentation until the indent becomes >= 8. The tab character size is excpected to be 8 and groups of 8 spaces are replaced with a tab character. Indent levels end up looking like 2 spaces, 4 spaces, 6 spaces, 1 tab, 1 tab + 2 spaces, and so on.
Implementation:
In the editor options, a new option, `editor.indentSize` is added. This, in conjunction with `editor.tabSize` has the same semantics as `indent_size` and `tab_width` in the well known [EditorConfig specification][1].
> indent_size: a whole number defining the number of columns used for each indentation level and the width of soft tabs (when supported). When set to "tab", the value of tab_width (if specified) will be used.
>
> tab_width: a whole number defining the number of columns used to represent a tab character. This defaults to the value of indent_size and doesn't usually need to be specified.
[1]: editorconfig.org
The new `indentSize` option takes a numeric value or "tab" just as EditorConfig's `indent_size`. The default value is set to "tab" so that current default behavior of VS Code does not change and existing user settings will not break.
When getting the new `indentSize` option programatically, it always returns a numeric value (just as `tabSize` does when set to the deprecated "auto" value).
In the text editor model, a new property is added for `indentSize`. Unlike the configuration options where the value of one property influences the other, In this code `tabSize` now should only mean "the width of the tab character" and `indentSize` should only mean "how may columns is one indent".
The cursor operations and shift command are updated to reflect these new semantics.
We compile using the alwaysStrict flag so these directives are not needed
This part removes most `use strict` directives that are right after the file header
After discussions, we settled on making the webview private unlike `TextEditors`. This means that webview events will live on the webview object itself
Fixes#44571
* Webview API prototype 3
Part of #43713
Third try at refining the webview api. This pass reworks #44165. Major changes:
- Adds an `id` field to webviews. The id is provided by the extension and identifies the webview. It is used with the new event handling apis.
- Adds a new `onDidChangeActiveEditor` api. This is similar to `onDidChangeActiveTextEditor` but is also fired when you change webviews. It replaces the old `onFocus` and `onBlur` events on the webview itself
- Adds an `onDispose` event ot webviews. This is fired when a webview is closed by the user
- Perist webview state when the editor group changes. This is enabled for all webviews, not just those with keep alive.
* Throw error when trying to access disposed webview
* Improving webview documentation
* Clean up dispose management
* Throw if we receive a bad handle
* Move more event handling to input
* Simplify input updating
* Remove extra container property
* Fixing md security alert button
* Remove extra update container call
* Restore syncing of preview to active editor
* Fixing posting to webview
* Debounce preview updates
* Remove previewUri
* Enable direct window.postMessage instead of window.parent.postMessage
* Fixing scroll position not preserved when updating previews
* Revert parent.postMessage change.
Old behavior was correct
* Properly hide webview container on tab switch
* Make sure we only handle scroll events for the correct document
* Don't try setting negative scroll
* Revert vs code whitespace change
