VisualStudioCode 1.19 released with improved performance and even easier use!

Hello.
I'm Mandai, the Wild team member in charge of development.

Just as I was feeling relieved after finishing my first ever writing job, I realized that a Visual Studio Code (VSCode) update had arrived ages ago!
I know it's a bit late, but let's take a look at this update! As

usual, I haven't covered everything, but I've focused on features that seem useful from a developer's perspective.

 

It's not flashy, it's performance

Since there don't seem to be any particularly noteworthy new features in the 1.19 update, I think the main topic is probably performance improvements.
Compared to the massive update in 1.18, the understated nature of 1.19 really stands out.

It seems that they have focused particularly on improving startup performance, and the improvements include the following:

• Startup and configuration performance improvements
• Improved performance by retrieving extension information from package.json during startup from cache
• Improved performance by delaying the launch of helper processes at startup (for processes like file watchers, file searches, and extensions)
• Improved file loading for faster startup
• Reworked the breakpoints view and explorer pane to use a faster list widget instead of a tree
• Improved performance by adjusting touch event handling
• Improved performance across the workbench by skipping unnecessary layouts and calculations that are not used
• Improved performance by removing code not used for startup

I've also experienced refactoring for performance improvements, and it's a rather mundane task.
The sense of satisfaction when your improvements work perfectly is incredible, but usually, all you get is a simple "It's faster now," so it often feels unrewarding.

That's why I understand how important an improvement this is! (Actually, I want to understand!)

 

There are a lot of command line arguments

I mostly launch VS Code on Windows, so I haven't actively used this feature much, but VS Code can also be launched from the command line.
For example, on Linux, you can type "code" in the terminal and the GUI screen will launch (I was a little surprised that there wasn't a command called "code").

A command-line argument called "--status" has been added, which displays VSCode version information, resource usage information (this shows CPU usage and memory usage per running process, as well as the parent-child relationships of processes), and workspace status. I've
never needed this kind of information in everyday use, so I think it's mainly a feature for extension developers.

The --status option seems to have another feature: it can display the resource usage of each VSCode process in the debug pane.
However, this feature does not appear to be included in the official version, and you need to add a module from GitHub.

In addition, it seems that it is now possible to pipe stdin (standard input) from the command line and have the piped information flow into the launched editor

I thought this could be used for error logs or something, but the mechanism for automatically logging to a specific file is standard in frameworks and such, so I guess it's used when you're messing around with shell scripts or something. I
can't think of a use case for it, so I'll keep this feature in mind and hopefully use it to show off someday.

This is completely unrelated, but speaking of logs, when you're working with a log file open, the content in the editor will be updated when the file is watched, but it would also be great if the display position could follow the end

 

Workbench tab behavior has changed

A new item called "workbench.editor.tabSizing" has been added to settings.json.
This setting determines how tabs are displayed when multiple editors are open, and the following two modes are available:

• fit
• shrink

If you select "fit" (which is the default), the tabs will never be smaller than a size where the titles are clearly visible.
The problem arises when you have too many tabs to display them all; (presumably) the oldest tabs will disappear, soCtrl + Tabyou'll need to pick them up from the list using

If you select "shrink," the tab size will become infinitely small, but as the number of tabs increases, the text will disappear and only the close icon will be displayed.
If you are confident that you can distinguish tabs even if only the first few characters are displayed,Ctrl + Tabinconvenient, then we recommend selecting shrink.

By the way, I also prefer using Shrink.
That said, if you hover your mouse cursor over the tab for a few seconds, the full file path will be displayed, so it's not really a big problem for me.

 

A simple but useful clipboard and file comparison

Added the ability to compare strings in a file and the clipboard

When comparing files on a different branch on GitHub with files on your local machine, you don't need to prepare the files each time; you can simply copy and paste the code from GitHub and compare it to the files on your local machine.
The above is a case where I actually used it, but I think there are other uses as well.

 

IntelliSense has gotten smarter

Even if you mistype "return" as "retun," IntelliSense will see right through it.
I wonder if it's measuring the Levenshtein distance or something.

 

The shortcuts for code folding have changed!

which folds only block commentsthe Ctrl + K → Ctrl + /shortcut,
I honestly thought it might be quite useful, but what do you all think?

 

Diff of image files managed by Git

This is also rather plain!
But I think many people manage their images with Git, and being able to display and compare them side-by-side is quite nice.

Since this is all there is to it, I was hesitant to include it, but the image comparing the orange VSCode icon with the new blue VSCode icon was..

 

summary

Version 1.19 also includes many updates focused on performance improvements, such as the ability to enable/disable extensions on a workspace-by-workspace basis

I imagine that workspaces with a huge number of files and VSCode with tons of extensions have seen significant performance improvements, but unfortunately, in my environment, I didn't notice a significant speed increase.
This doesn't mean the improvements were pointless; it's just that my environment, which only uses it lightly, is the problem.

Depending on the large-scale development or development language, I sometimes find myself resorting to Eclipse, so in 2018 I hope to be able to write code using only VSCode

 
That's all