Improved performance makes it even easier to use! Visual Studio Code 1.19 released!

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

After finishing my first writing job, I was relieved, but then I realized that the version update for Visual Studio Code (hereinafter referred to as VSCode) was long overdue!
I know it's too late, but let's take a look at this version update!

As usual, we do not provide an exhaustive list, but we have focused on features that would be beneficial if you knew them from a developer's perspective.

 

A story about performance without flashiness

I don't see any major new features in the 1.19 update, so I think performance improvements are the main topic.
Since 1.18 was a big deal, the plainness of 1.19 shines through.

It seems that they focused on improving performance at startup, and the improvements are as follows.

• Performance improvements around startup and configuration
• Improved performance by retrieving extension information obtained from package.json from the cache to be used during startup.
• Improve performance by delaying the startup of helper processes at startup (targeting processes such as file monitors, file searches, and extensions)
• For faster startup. Improvements related to file loading
• Reworked the breakpoints view (you mean the breakpoints item in the debug pane?) and explorer pane to use a faster list widget instead of the tree.
• Improve performance by adjusting touch event handling
• Improve overall workbench performance by skipping unused layouts and calculations
• Improve performance by removing code not used for startup

I have some experience with refactoring to improve performance, but it's a simple process.
The feeling of self-satisfaction you get when your improvements are perfect is incredible, but most of the time, the only thing you can say is, "You've gotten faster," so it's often not rewarding.

Because I'm like that, I understand how important an improvement this is! (No, I want to understand)

 

Are there more command line arguments?

I mostly start VSCode on Windows, so I didn't actively use it, but VSCode can also be started from the command line.
For example, on Linux, etc., if you type "code" in the terminal, the GUI screen will start (I was a little shocked that there was no command called "code").

"--status" has been added as a command line argument, and the version information of VSCode and the resource information being used (this displays the CPU usage rate and memory usage for each running process, and the parent and child of the process. (relationships are displayed) and the workspace status is displayed.
I've never had a situation where I needed this kind of information in everyday use, so I guess it's mainly a feature for extension developers.

The --status option seems to have another function: it can display the resource usage of each VSCode process in the debug pane.
However, this feature does not seem to be included in the official version, and you will need to add the module available on github.

Other than that, it seems that it is now possible to pipe the stdin (standard input) of the command line and flow the piped information onto the launched editor.

I was wondering if this could be used for something like error logging, but since the mechanism for distributing logs to a fixed file is a standard feature when using frameworks etc., it can be used when running shell scripts etc. Is it?
I can't think of any use cases for it, so I'll keep this feature somewhere in my heart and think I'd like to do it someday.

This is completely unrelated, but in terms of logs, when I work while opening a log file, the content on the editor will be the latest when it is updated by file monitoring, but the display position will also follow the last one. It would be really nice if you could do that.

 

Workbench tab behavior has changed

An item called "workbench.editor.tabSizing" has been added to settings.json.
This is a setting for how tabs are displayed when multiple editors are launched, and the following two modes are available.

• fit
• shrink

If you choose "fit" (this is the default), the tab will not be smaller than the size that ensures the title is visible.
The problem is when there are too many tabs to display, and (probably) the oldest tabs are no longer displayed, so you have to use Ctrl + Tab

If you select "shrink", the size of the tabs will become infinitely small, but as the number of tabs increases, a phenomenon will occur where no text will be displayed and only the close icon will be displayed.
If you are confident that you can distinguish the text even if only the first few characters are displayed, or Ctrl + Tab , we recommend choosing shrink.

By the way, I'm also a shrink fan.
However, if you hover your mouse cursor over the tab for a few seconds, the full path of the file will be displayed, so it's not that much of a problem.

 

Simple and convenient comparison of clipboard and files

Added the ability to compare files and strings in the clipboard.

If you want to compare a file from another branch on github with a file locally, you can copy and paste the code from github and compare it with your local file without having to prepare each file. That's how it is.
The above is a case in which I actually used it, but I think there are other uses as well.

 

IntelliSense is now smarter

Even if you type return as retun, IntelliSense will still see it.
Is it also measured by Levenshtein distance?

 

The shortcuts around code folding have changed!

the Ctrl + K → Ctrl + / shortcut
that only folds block comments I honestly thought it might be useful, what do you think?

 

diff of image files managed by Git

This is also plain!
However, I think that images are often managed with Git, and I think it's quite nice to be able to display them side-by-side and compare them.

Since this is all there is to it, I wasn't sure whether to bring it up, but the image I was comparing when the version update was released was an orange VSCode icon and a new blue VSCode icon...

 

summary

1.19 also included many updates focused on performance improvements, such as the ability to enable/disable extensions on a workspace basis.

I think that the behavior of workspaces with a large number of files and VSCode, which register many extensions, has improved considerably, but in my environment, sadly, it was not fast enough to be noticeable. .
This doesn't mean that the improvements were wasted, but rather that my environment is bad because I only use it lightly.

Depending on the large-scale development or development language, I sometimes end up running away to Eclipse, so in 2018 I think it would be good to write code only with VSCode.

 
That's it.