Vscode: Reviewing our Default Settings

[seanmcbreen]

Reviewing Default Settings

One of the tasks for this iteration is to make a proposal to alter the default for some of our settings. This is a discussion issue to solicit feedback on a proposal for change. We are looking at making some changes to improve the discovery of some of our key features and to address user feedback.

Part of a broader assessment of settings

Before I even get going it's worth sharing some context that this is part of a broader set of investigations that will occur over the next few months. Some additional context on the broader considerations is contained in issue #26892.

Overview of Changes

NOTE: Changing the default settings will change the behavior for all users of VS Code - existing and new. So the lists below are broken into three sections to try an avoid making changes unnecessarily for all users.

• Everyone's Defaults - a proposal that will impact all users
• Update Process - although not directly related this will also impact all users
• Specific Users - proposal's that relate to a specific set of users only e.g. those coming from Sublime

Changes to Everyone's Defaults

The following settings address the most common feedback we heard from users:

Setting | Current | Proposed | Notes
--------|-----------------|------------------|------
editor.minimap.enabled|false|true
workbench.iconTheme|none|vs-seti
editor.dragAndDrop|false|true
window.openFilesInNewWindow|default|off
editor.renderIndentGuides|false|true
editor.renderWhitespace|none|boundary
extensions.autoUpdate|false|true

This next group we hear less often but none-the-less are candidates for a change in default, for these cases there may be solid reasons [beyond a preference] why a default change is a bad idea. for instance we may already be experimenting with a default change, or working through some user feedback.

Setting | Current | Proposed | Notes
--------|-----------------|------------------|------
editor.mouseWheelZoom|false|true
debug.inlineValues|false|true
workbench.editor.revealIfOpen|false|true
typescript.implementationsCodeLens.enabled|false|true
javascript.implicitProjectConfig.checkJs|false|true
javascript.referencesCodeLens.enabled|false|true

Bundling a Programmers MonoSpace Font

We are also considering bundling a font with VS Code to ensure that everyone has a good experience across all platforms from install onwards - more context in this issue.

Changes to Update Process

We are also proposing a few behavior changes to the update process - this will better preserve the users last working state before the update. While these are actually not a change to the default settings they do have the same effect as changing the following settings which come into effect when you close VS Code and re-open it manually.

Setting | Current | Proposed | Notes
--------|-----------------|------------------|------
window.reopenFolders|false|all|Only here for reference - applies to update only
window.restoreFullscreen|false|true|Only here for reference - applies to update only

Changes to Specific Users

Sublime, Visual Studio

May users from Sublime and Visual Studio miss the fact we offer multi-cursor support and column/box selection, these changes would let their muscle memory work better :) We are only proposing these changes for this class of users as it would otherwise change the goto definition binding for all users without warning.

Setting | Current Default | Proposed Default | Notes
--------|-----------------|------------------|------
editor.multiCursor.enableCtrlClick|false|true|Would swap behavior of ctrl/alt + click
editor.selection.enableCtrlDragColumn|false|true|Would swap the behavior of ctrl/alt + click & drag

Ok thats the proposal - let us know what you think.

Sean

[mjbvz]

I recommend against enabling javascript.implicitProjectConfig.checkJs by default. It's a cool feature but is not perfect, and it may result in a lot of noise in some js codebases

[Tyriar]

window.restoreFullscreen

I don't think most applications do this so we probably shouldn't.

Changes to Specific Users
Sublime, Visual Studio

How would these changes be served to only sublime and VS users?

[seanmcbreen]

@mjbvz - I thought you may say that. You are the expert here so lets consider this only when the time is right. It's super cool but it should also be super high quality :)

@Tyriar - Good point on full screen, Chrome certainly does not do it and of the settings for update it's the less important of the two. For the editor specific stuff we would find a way to add it into the keymaps or create an extension pack that did settings + depended on the keymaps. So for a new user they need to take a step to get there but if they want symmetrical behavior that is already the case.

[bpasero]

@seanmcbreen some feedback on some settings I own:

• openFilesInNewWindow: I would not change this, on Linux and Windows this already behaves as you like (files open in same instance). however on macOS users will expect more native behaviour and it is very common to have files open in separate windows under certain cases (open from dock, open from finder). did we get feedback on macOS about this behaviour that we want to change it?
• workbench.editor.revealIfOpen: I think the train has left the station for this one to change, it would be a big big behaviour change that might confuse more than it aids
• window.reopenFolders and window.restoreFullscreen already behave the way you describe when an update is received, independent from the setting. if not, please file a separate issue as bug

Here are more candidates from me:

• editor.codeLens: false: codelens is not ready for prime time, sorry (just compare it to VS). it looks like we changed it to be enabled by default in this milestone
• files.autoSave: afterDelay
• editor.formatOnSave: true
• editor.formatOnPaste: true

[egamma]

Regarding formatOnPaste

[isidorn]

debug.inlineValues is not good enough for prime time, same as codeLense - I would keep both of them to false.

Agree with ben for autoSave and formatOnSave and formatOnPaste. Let's try to do something different and cool than all the other editors and finally have that autoSave on!

-1 for dragAndDrop default = true, this feature can by accident screw up with a users flow if he is not expecting it. Do we see people asking for this to be on by default?

I would consider making some cool font the default and enabling fontLigatures by default.

[Tyriar]

-1 to files.autoSave. This would really confuse me jumping into a new editor and break my flow. I often start working on changes and not save them while there is a watch or compile command running (this is particular bothersome for compiled languages). I think the right way to better surface this setting is to highlight some of the core features like this, maybe on the welcome screen or on first launch somehow.

-1 to editor.formatOnSave and editor.formatOnPaste. Formatters need to be configured or they will almost certainly not match the project's configuration. Save should save the file by default, not change it and then save it.

---

While it's certainly easier to disable features that annoy you rather than discover features that will delight you, differing the initial experience too much from what's "expected" could cause some users to drop off faster.

[kieferrm]

• I'm not in favor of "editor.dragAndDrop": true. I need to be too careful to no make unintentional changes.
• I'm a big autosave fan but I understand @Tyriar's concerns.
• editor.formatOnPaste should be enabled by default. There could certainly be issues with how the formatter is configured compared to the project defaults but that's also an issue with the format command in general.
• We should only use "editor.renderWhitespace": "boundary" or "editor.renderIndentGuides": true. Both at the same time clutter the text too much.
• For mac users I'd also like to see "files.hotExit": "onExitAndWindowClose" and "workbench.editor.tabCloseButton": "left".

[Tyriar]

Probably wouldn't make sense to use "files.hotExit": "onExitAndWindowClose" just for macOS as it impacts the other OS's in a very similar manner. I've seen maybe 3-4 issues reported about hot exit not working when they actually want onExitAndWindowClose, I still stand behind the onExit being the safer option that will result in the least friction.

[bpasero]

@Tyriar must be tons of IntelliJ users be very frustrated that auto-save is enabled by default. As far as I learned, you cannot even disable it in their IDEs (this includes Webstorm).

[Tyriar]

@bpasero a quick search finds that there indeed are some very frustrated users:

If you come from a different IDE such as Eclipse, you will be unpleasantly surprised to find that JetBrains-branded IDEs automatically save everything the moment you look away. The proponents argue that as you work on your project, you should not have to worry about saving files. But to others, this auto-save behavior which is enabled by default is a curse that catches them by surprise, and a shocking departure from the workflow they are very much used to.

http://thehunk.blogspot.com/2015/07/disable-auto-save-in-jetbrains-ide.html

The problem is that with Webstorm's auto-saving, meteor would push changes way too often, frequently causing compile errors on the server side Node.JS, and sometimes breaking the server. I had to find a way to disable autosave.

https://intellij-support.jetbrains.com/hc/en-us/community/posts/207054215-Disabling-autosave

This is really frustrating when I have auto-makes, which mess up TomCat, or watches on files via Grunt, Karma, etc when doing JS development.

http://stackoverflow.com/q/28949290/1156119

[bpasero]

@Tyriar not sure that is fair to compare with us: those users have no choice of disabling auto save but we have many options to configure this.

[isidorn]

@bpasero @Tyriar if I there ever was a need for an experiment this is it. Let's just enable it for 5% of our users and see the reaction.

[egamma]

I'm not in favor of "editor.dragAndDrop": true . I need to be too careful to no make unintentional changes.

Most editors I've used NotePad++, Intellij, Sublime, Eclipse have drag&drop enabled by default. This worked OK for me. Before deciding to not make it the default, we should understand whether our implementation needs more tuning to avoid making unintentional changes.

[alexdima]

Regarding editor.mouseWheelZoom, we cannot differentiate mouse wheel events coming in from a mouse vs. coming in from a trackpad. It has been reported multiple times that on mac laptops it is very easy to trigger the editor zooming by accident while typing.

I also believe we should change that ctrl++ and ctrl+- zooms in the entire workbench -- this is implemented by Chromium and it has many known bugs. We should instead bind to ctrl++ and ctrl+- a font size increase / decrease (i.e. similar to mouseWheelZoom)

If we're doing the big breaking change, I believe we should also tackle now:

• shipping a good monospace font, especially on Ubuntu - #5742
• changing the default theme to e.g. monokai
• changing "editor.wrappingIndent": "same" to indent

[Tyriar]

We should instead bind to ctrl++ and ctrl+- a font size increase / decrease (i.e. similar to mouseWheelZoom)

I find zooming the whole workbench to be much more useful than zooming just the editor, if I'm too far from the monitor and can't read the text I want to be able to read the panel/sidebar too.

[bpasero]

-1 for changing zooming keybinding. if this is about avoiding issues with chrome zooming we should invest in making workbench zooming better.

+1 for thinking about a different default theme now that we have workbench theming. also +1 for changing our default fonts and enabling ligatures for example.

[alexdima]

@bpasero Here are the zooming issues -- please feel free to tackle them

[ramya-rao-a]

Recommendation to start with docs expanded in the suggest widget instead of the collapsed docs.
See https://github.com/Microsoft/vscode/issues/18582#issuecomment-302530068

FYI There is no setting here.

If we decide to change the default, it would be a code change.

[seanmcbreen]

Update

Looking through the discussion this is my recommendation for how we proceed. I've created three lists, settings where:

1. we should change the default now - these are the ones with little debate
2. we will not change the default - these had a little more debate to them or could be solved another way

Timelines

This note is the summary and n the next week we will go ahead and make the updates from list 1 in time for the next release.

Settings where the defaults will change in the next release

Setting | Current | Proposed | Notes
--------|-----------------|------------------|------
editor.minimap.enabled|false|true|No push-back and the common setting in other editors
workbench.iconTheme|none|vs-seti|No push-back
editor.dragAndDrop|false|true|This is the common behavior for other editors
window.openFilesInNewWindow|default|off|This is the common behavior in other editors
editor.renderIndentGuides|false|true|Common settings in other editors
extensions.autoUpdate|false|true|No push-back
editor.mouseWheelZoom|false|true|Common request from users, default for other editors and has a modifier ctrl
editor.formatOnPaste|false|true|Common customer request, aid in discoverability

A few additional comments:

1. Shipping a font, we are working on being able to ship a font.
2. This is just a first step in several ideas for improving settings #26892. So we will have the opportunity to revisit some of this.

Settings we will not change the defaults of

This is the list of other settings discussed in the thread that I suggest we don’t change the defaults for right now.

Setting | Current | Proposed | Notes
--------|-----------------|------------------|------
editor.formatOnSave|false|true|Since we have on-paste I opted for just one of the two suggested
files.autosave|off|afterDelay|May disrupt many - let’s see if we can better surface in UI
editor.wrappingIndent|same|indent|For discussion I found indent was a confusing change
workbench.editor.revealIfOpen|false|true|I did not have a lot of data suggesting this was an issue for most users
workbench.colorTheme|Default Dark+|Monaki|We have not had a large number of request this and people seam to be discovering the other options
editor.renderWhitespace|none|boundary|Took advice to focus on ident guides as a starting point
debug.inlineValues|false|true|Wait for prime time
typescript.implementationsCodeLens.enabled|false|true|Wait for prime time
javascript.implicitProjectConfig.checkJs|false|true|Wait for prime time
javascript.referencesCodeLens.enabled|false|true|Wait for prime time

Ok, with my attempt at a summary out let’s see if there is significant debate over any of this. If now we will move onto implementing these changes.

Sean

[alexdima]

@seanmcbreen

Please see my comment above:

Regarding editor.mouseWheelZoom, we cannot differentiate mouse wheel events coming in from a mouse vs. coming in from a trackpad. It has been reported multiple times that on mac laptops it is very easy to trigger the editor zooming by accident while typing.

i.e. you cannot work with the editor on a mac laptop if this setting is on. And we cannot address it because we don't know if the mouse wheel event comes from the trackpad or from a real mouse. I suggest someone does a lot of work on a mac laptop's built-in keyboard/trackpad with this setting turned on before we turn it on for everybody.

[seanmcbreen]

@alexandrudima just to press a tiny bit (but for now to be clear we will not change this default i.e. we will leave it as false) but to help me understand/get educated... I'm struggling with two things.

1. Sublime and word have this enabled by default - is there a reason they don';t have this issue i.e. do you think they can tell the source of the scroll indication i.e. the mouse wheel and that's what makes it OK for them?
2. Does the addition of a modifier not reduce the risk i.e. you need to press ctrl+wheel.

I guess I'm looking to understand the false trigger case - is it when the user is attempting the place a cursor and we instead zoom? [but that's alt+click] or some other common gesture I'm missing?

I've personally not seen the issue and would love to know how to repro it.
Sean

[roblourens]

The difference is probably that we're getting DOM events from the browser that give us less info than native events that Sublime and Word could be using.

But I agree that mouseWheelZoom is unusable on a macbook. When you scroll with scroll inertia, then press ctrl or cmd, that's handled the same as if you were scrolling while holding ctrl.

If you have a macbook handy, just try scrolling with inertia and pressing cmd after your hand is off the trackpad.

I've also encountered this like when scrolling the editor with inertia, then opening the panel - now the remaining scroll inertia is directed into the console or output panel which is unexpected, but I suspect we can't tell the difference between scroll inertia and a purposeful scroll.

[roblourens]

Actually, Word does exactly the same thing with inertia scroll...

[seanmcbreen]

Ok that helps me understand - we'll leave it as is.

[Tyriar]

Should it be false on Mac, true on Windows/Linux? I believe this matches Chrome's behavior.

[seanmcbreen]

I think for now we can skip this one setting editor.mouseWheelZoom and proceed with the rest. For now I'd love to avoid making any OS specific changes - at least for now :)

[jhasse]

Shipping a font, we are working on being able to ship a font.

Some arguments against that:

1. People might have configured their fonts differently (e.g. aliases) and VS Code would then ignore that setting by default
2. Increased distribution size
3. Increased CPU consumption and memory usage: The font needs to be loaded, system fonts are already used most of the time
4. One font might not fit all operation systems, since they use different rendering libraries
5. Font bugs can't be fixed by operating system updates anymore
6. Powerline users might run into problems (https://github.com/powerline/fonts)