I’ve been using VS Code for quite some time now. In fact, given the nature of my work recently I’ve found myself spending more time in VS Code than in VS 2017 over the past several months. The “out-of-the-box”, “stock” experience with VS Code is truly fantastic and has provided me with just about all the functionality I’ve needed.
Given that I’ve never really paid much attention to the settings I thought I should dive in, look over the nearly 500 settings, and highlight a few which I found most interesting. Although the vast majority are pretty typical for an editor there are plenty that can have a significant impact on the way we work so without further ado, here are my picks for the top 15 most interesting VS Code settings!
Out-of-the-box, VS Code’s title bar provides minimal information about what’s being edited. The information provided might be sufficient for small projects or individual files but as projects grow it might not be enough. For example, how many files named
index.js does your latest node.js project contain?
window.title gives us a relatively straightforward way to customize the information shown in the title bar by providing us with a series of variables we can include in a string template. The default settings document details the variables so I won’t go into detail about them here but I will say that I’ve found the following quite useful:
After opening VS Code for the first time and exploring the UI a bit you’re likely to close all of the editor windows and stumble upon this nice watermark image and a few tips for returning to a productive state. Over time however, you’re likely to internalize most of the tips and you might not want to see them any more. By changing
false you can rid yourself of them and get rid of some of the clutter.
It’s a subtle change but I really like just having the faint VS logo.
If you do any number of presentations that rely on VS Code or you like to control when your software updates are installed the
update.channel setting will likely be of interest to you. Setting this value to
none and restarting the editor will prevent any new releases from being installed and potentially interfering with any of your demos!
Once you’ve set
none and are ready to apply any available updates you can do so by selecting the
Check for Updates option under the
Code menu on the Mac or the
Help menu on Windows.
I do much of my writing in markdown. Even write most of my blog posts start off in markdown before I move them to WordPress when I’m ready to publish. As convenient as that is, I often find that I’d like to customize how the preview window renders the text, be it for my stylistic preference or to match the styles in a given project. That’s where the
markdown.styles setting comes in.
The help text displayed for the
markdown.styles setting in the master settings file reads as follows:
A list of URLs or local paths to CSS style sheets to use from the markdown preview. Relative paths are interpreted relative to the folder open in the explorer. If there is no open folder, they are interpreted relative to the location of the markdown file. All ‘\’ need to be written as ‘\’.
I point this out because it reveals a number of intricacies about the setting. First, it takes an array of file names. This allows us to split our CSS into several files or allow the CSS to vary by project. Next, the file names are all relative to either the current markdown file OR the folder open in the VS Code Explorer. Since the paths are relative we can share CSS between markdown files or projects based on our file organization structure.
Note: You’ll need to close and re-open the preview after changing this setting or the referenced CSS for the changes to be reflected in the preview window.
Although changing the font is something that one would expect from any text editor, I particularly appreciate that VS Code allows us to control whether ligatures are rendered for the fonts that support them.
One such font that I like is Fira Code, a programming font specifically designed with ligatures in mind. In Fira Code, ligatures are used for a number of multi-character operators such as equality, inequality, piping, and so on as a single glyph rather than several thus allowing the code to [arguably] look a bit cleaner. The underlying characters all remain intact, I just think it just looks better.
Not everyone likes the ligatures for a multitude of reasons so they’re disabled by default but by changing the
editor.fontLigatures setting to
true we can take advantage of them in VS Code. Of course, if you enable the setting and decide you don’t like them, you can always return the value to its default.
Although I don’t spend much time in F# these days one thing I got used to was caring about seeing whitespace in my code since whitespace is significant there. I got so used to seeing whitespace in my code that I even turned on the feature in Word for my more formal writing. Unfortunately, showing whitespace in the full Visual Studio is a binary proposition; you either see all whitespace characters or none. I’ve often wished for some balance between the two options.
editor.renderWhitespace setting takes this capability beyond what Visual Studio traditionally offers by providing a third option,
boundary, which offers what I consider to be the best of both worlds. The
boundary setting essentially shows leading and trailing whitespace while ignoring single whitespace characters between words or syntax elements.
This is another setting with a subtle visual effect that can greatly affect your experience when using VS Code.
By default, the text cursor is rendered as a solid vertical bar but there are plenty of other styles in other editors. In VS Code we can change the
editor.cursorStyle setting to adjust the cursor to something else that we may be more accustomed to, be it a vertical line, underscore, or even a box.
There’s also an
editor.cursorBlinking setting which controls how the cursor blinks. I prefer the
solid or default
blink values but you can also choose
I encourage you to experiment with various combinations of the
editor.cursorBlinking settings to choose one that works best for you. I thought the expanding block-outline was fun for a bit but found it pretty distracting overall. Now I’m back to using a boring solid line.
If you’re working on a team, chances are that your teammates are pushing changes to the same remote repository that you are. The
git.autoFetch setting toggles whether VS Code automatically fetches those changes from the remote so you can see what’s happening in the repository without integrating the changes immediately. I think it’s a nice feature but if you enable it for daily use you may consider disabling it when working on a plane. Oops!
VS Code’s minimap is a nice feature which shows you an overview of your code’s structure. It comes with a few customization options that I think greatly enhance its usefulness.
editor.minimap.renderCharacters. By default the minimap renders a pixelated view that attempts to replicate the characters in your code. Given how small the box is, I don’t find it particularly useful to render that way since most of the information is lost. Instead, I prefer to disable that option so the map renders blocks that represent the structure.
editor.minimap.showSlider. This setting merely toggles when the region of the file currently visible in the editor window is highlighted in the map. By default, this is set to show only when the pointer is over the map. I tend to leave this setting alone but it can also be set to
always so that it’s always shown.
Another interesting minimap setting is
editor.minimap.maxColumn. Changing this value affects the minimap’s width based on the number of textual columns in the code. The default is 120.
We can also control whether the minimap appears on the right or left side of the code listing with the
editor.minimap.side setting. By default the minimap appears on the right. I’ve played with both sides and see merits to both. When on the right, the minimap takes advantage of existing whitespace but it often quite some distance from the code. On the other hand, placing the minimap on the left increases the margin size but places the map much closer to most of the code. I tend to keep the minimap on the right to take advantage of that existing whitespace.
Finally, the minimap isn’t for everyone so like so many other VS Code features, you can turn it off by setting
debug.internalConsoleOptions setting. This setting takes one of three values:
||Does not automatically open the debug console|
||Opens the debug console when the first debugging session starts|
||Opens the debug console every time a debugging session starts|
debug.internalConsoleOptions is set to
openOnFirstSessionStart but I prefer
openOnSessionStart if for no reason other than starting each debugging session at a consistent place.
Much like the
debug.openExplorerOnEnd controls affects VS Code’s behavior when working with debugging sessions. Where the
debug.internalConsoleOption setting can surface the debug console when debugging starts,
debug.openExplorerOnEnd surfaces the main explorer window when debugging ends. Be default this behavior is disabled but it can be convenient for remaining focused on your project structure whenever you return to editing.
When we open a folder in VS Code the explorer shows us a listing of that folder’s contents. Most of the time there are certain files or subfolders (such as .git) that we don’t want to see. VS Code’s
files.exclude setting is an object that indicates whether certain glob patterns should be shown.
By default, the major version control system folders are hidden along with some other “special” folders (such as
.DS_Store) that are used by the underlying operating system.
A related setting is
search.exclude which behaves similar to
files.exclude except that it specifies glob patterns to exclude from VS Code’s built-in search capabilities. Paths you may choose to exclude from the search feature would be things like the
What I think makes this pair of settings so interesting is that
search.exclude inherits the values from
files.exclude so those globs are automatically excluded from search results while other patterns can still be shown in the explorer panel but excluded from searches.
var that I can click in multiple, non-sequential places in my code and replace change them to
let. The problem is, I always seem to hold the wrong key, particularly when jumping between my Mac and Windows devices.
editor.multiCursorModifier setting defaults to
alt but I much prefer the
ctrlCmd value. Now, regardless of which laptop I’m on, I press what is essentially the same key.
Another of my favorite VS Code features is hot exit. Hot exit is VS Code’s ability to remember unsaved changes when VS Code is closed. This has proven fantastically useful for me when I’ve been keeping a scratchpad going and need to reboot to apply the latest system updates or accidentally close my VS Code windows.
By default, hot exit is set to trigger
onExit but you can customize the behavior by changing the
files.hotExit setting to
off to disable, or
onExitAndWindowClose to apply the effect to editor windows not tied to a particular folder.
Finally we reach what has quickly become one of my favorite VS Code features – auto save. Although disabled by default VS Code gives us plenty of variety when it comes to managing this behavior via the
To automatically save all changed files when we focus away from VS Code we can use the
onWindowChange option. Similarly, we can use the
onFocusChange value to save any changes when focus leaves the editor. And then there’s my personal favorite:
autoSaveDelay which saves any changes after some interval specified by the
files.autoSaveDelay setting. By default, this automatically saves changes every second but you can adjust it to your needs.
Although I definitely prefer the
autoSaveDelay option I will offer one word of warning – don’t use it with
nodemon or anything else that automatically rebuilds/reloads a project. Since you’ll likely be in the middle of typing some expression or statement when the interval hits, those processes are likely going to hit code that’s a work-in-progress and throw some errors.
So there they are – my 15 picks for most interesting VS Code settings. I did intentionally exclude some extension-specific settings from this list but I think these are definitely some of the most impactful settings for a variety of environments.
Did I miss any settings you find especially interesting? Let me know and I’ll see about putting together another list.