I'm in the process of switching to or at least trying out Visual Studio Code.

I'm not familiar with every editor but I certainly know that an expandable editor is not a new thing. Emacs is as old as dirt and has been customizable since it was first created. vi has been customizable just as long I'm guessing. Brief, a DOS based editor from the late 80s was probably the first editor I customized a bunch with custom scripts.

For whatever reason though Visual Studio Code feels like it's done something new. I think the biggest thing it did (and I get that I might have gotten this from Atom) is not just to have an extension system but to actually integrate an extension browser/market directly in the product. Most other extensible editors require digging deeply into the manual to find out how to add an extension and then you're left on your own to find them. VSCode on the other hand asks you when you start or you can just click one of the main icons.

If that was all it brought that might be enough but it seems to have brought a few other innovations (expect to get corrected in the comments). One is that Microsoft designed an asynchronous language server protocol for heavy processes to run outside the editor. So for example if you want to have a C++ linter that runs LLVM to find places to warn you you don't have to put it in the editor and have it slow down your editing. Rather you run it as an external process, it can take as long as it needs and provide the result asynchronously.

Some editors did stuff like that but they didn't define a standard for it, instead it was just built in to their few custom linters. VSCode on the other hand, because it defined a standard opened that up to add support for any language. Write the linter, interface using the protocol, install, BOOM! Your editor now supports a new language. They even suggested other editors consider supporting the same protocol so they can take advantage of the same linters.

Maybe other editors support a similar feature but I was kind of blown away at some of the lint warnings I saw. For example I recently started playing with React. I followed the docs but of course things change over time. I followed some instructions that said to install the React linter into VSCode and suddently I was getting super React specific linter warnings directly in my editor. Is that a common thing anywhere else? I've certainly seen lint warnings for the language itself but I've never seen them for specific libraries.

It also helps, at least for JavaScript, that there's is almost a defacto standard for declaring your dependencies. This means the editor can easily look them up and know which linters to run. Of course you can also manually specify them but dang, that's pretty awesome.

Another feature I hadn't seen so much before is AST based linters that can expose correctors. I've seen a linter tell me "2 spaces required here" or "must use double quotes" but I hadn't seen "Fix all occurrences of this issue" before. Of course I've seen re−formatters before but they were generally all or nothing. You run your entire file through, it reformats everything, you get stuff out the other end. Some of you might like that kind of stuff but I'm not a fan as I find I generally want more flexibility than most coding standards provide.

This is not VSCode related but that brings up yet another thing which is the most common linter for JavaScript is eslint and not only is it massively configurable but it also takes plugins. That means unlike most linters I'm familiar with eslint you can relatively easily customize it for your personal style instead of just having to pick one of a few presets. Similarly the way these are specified are someone standardized so VSCode can adapt to difference lint settings per project.

Unfortunately VSCode is still missing many things I'm used to. Some might be easy to add as plugins. Others will require big changes I can only pray the team will make

Big needs include recordable keyboard macros. That's a feature I've used often for over 30 years and it's a little hard to believe that it wasn't part of the MVP for VSCode. It even exists in Visual Studio.aspx). It requires a certain level of architecture at a deep level. Hopefully that architecture is already in place.

Another personal big need is support for unlimited window splitting. As it is VSCode is hardcoded to 3 vertical splits period. No horizontal splits. No 2x2. Emacs since the 80s has had unlimited spitting. In this age of 30inch monitors a limit of 3 splits, and only vertical splits, seems very limiting.

Yet another is support for column editing. VSCode has support for multiple cursors and that's great but it's not a substitute for column editing.

Similarly in my old editor there are at least 3 modes of selecting. (1) Normal character to character select. (2) line select (3) column select. You press Alt−M (or just hold shift) for the normal character to character select, Alt−L switches to line select, Alt−C to column select. Moving the cursor keys once in selection mode adjusts the selection. Pressing almost anything else stops selecting which basically means you need the editor to tell you some other key was pressed. Just assigning a function to get called on Alt−L, Alt−M, Alt−C is not enough.

Mapping the keys might be easy but handling virtual space not so much.

Those things probably need core changes to the editor's internals. The following can probably just be done with extensions some of which might already exist.

Less mouse dependence. I could be I'm just not used to it yet but in my previous editor there is an optional custom open dialog that doesn't need a mouse. The default is to use the OS's open dialog but when editing I find that a PITA. Another is a buffer selector. Some people might see this as the same as file selector but for some reason I find it useful to be able to switch among the short list of files I have open rather than the entire list of files in my project. Plugins for those probably would not be that hard.

Another is to be able to search and replace based on coloring or the AST. Example: search and replace "for" with "four" but only in strings. Without that feature every for loop would get replaced. Or search and replace "which" with "witch" but only in identifiers.

More auto formatting would be nice. It's possible it already exists and I just have to configure or turn it on. As a higher level example my old editor could auto wrap comments

And it's also aware when I'm in a comment block and knows to indent the next line with a comment. It's probably just a minor tweak to the current auto indent which looks at the previous line.

This one might require callback/event support but my previous editor keeps backups and I can visit and diff them

You probably thinking I should use git for that but that's not really the point. The point is this just happens in the background and saves me from when I haven't committed to git yet or when I'm working on a file not related to software dev.

One more is safe multi−file search and replace. Basically my current editor can search and replace across files and then undo the entire thing. Of course without that feature I could manually backup first, then do my search and replace but it's so much nicer just to be able to do it without thinking about it.

I'm not entirely sure I want to switch but I do find some of the new features compelling so I'm hoping I can get VSCode customized to surpass my previous editor.