Choosing the Editor

As I mentioned in one of my previous notes, an integrated development environment is something very natural for me. I feel more comfortable using "the whole package" rather than thinking about compiling, linking, debugging, profiling, UI building, etc. as about separate activities requiring separate tools. And yet, the "IDE approach" isn’t universal. I can’t have a full-fledged IDE for every language I use, and I don’t really need all the tools related to this or that technology. I use some languages often, other languages rarely, and occasionally play with the rest. I also have to edit JSONs, XMLs, INIs; write Markdown and Asciidoc files, and so on. Arguably, there is some "perfect" tool for each of these tasks, but it is also quite taxing to learn so many tools just to use them once a month.

Thus, I believe our primary tools should be shiny and well-equipped, but for less frequent tasks something universal and flexible would suit better. Currently I tend to use MS Visual Studio for C++ and .Net languages, and Visual Studio Code for the majority of other tasks related to text editing and programming. I am a Windows user, so Visual Studio is an easy choice, especially given my long experience with it. Quite a while ago I experimented with IntelliJ IDEA and PyCharm. They are undoubtedly very high-quality products, but back then I found them slow and conceptually quite different from Visual Studio, which made me feel uncomfortable. Visual Studio team made a great effort to minimize the difference in responsiveness, but it is still somewhat unpleasant to jump between MS and JetBrains IDEs.

When Visual Studio Code got released, I decided to give it a try. It looked like a natural choice for someone already comfortable with Visual Studio and not really willing to invest massive effort into learning and customizing something like Vim or Emacs. There is also, of course, a hugely popular Sublime Text, but I somehow got under the influence of the hype around VS Code, and wasn’t sure about Sublime’s future in the long run.

I am saying all that just to share some of my pains on the way to choosing the daily workhorse tool. I tend to select something, learn it well, and use extensively. Visual Studio Code has its share of quirks and debatable design decisions, and it epitomizes the good and the bad of modern software. However, in overall, it serves me well. My today’s plan is to share a couple of observations and give a quick overview of language-independent extensions, greatly contributing to the quality of my work.

What is "Modern"

Generally, I believe in "the fewer moving parts, the better" philosophy. In this sense, I’d prefer having a natively compiled system with optional plugins, but without any complex third-party dependencies and multiple possible points of failure, some of them very obscure. Unfortunately, Visual Studio Code follows a very popular strategy of today by relying on Electron, essentially a combination of a portable Chromium engine with a Node.js framework. Normally, one shouldn’t care which tools are used to develop a particular software. However, Electron won’t let you forget: high memory footprint, slow start (yes, it is noticeable), obscure errors…​ For example, one bug I faced personally prevented VS Code from starting on a machine without active internet connection. There are simply too many subsystems there, and some of them depend on seemingly unrelated components such as firewalls, networking protocols and other system settings. Any update of any of these components might easily break main functionality or third-party extensions. Needless to say that you are constantly getting those annoying update notification popups during work, as if some small status icon isn’t sufficient.

Having said that I am unhappy with this choice of Microsoft developers (after all, why won’t they use their own technologies?), I must say that the final result is much better that one might have expected. Yes, annoying things happen, but they aren’t as common as in many other projects. Say, Thunderbird breaks extensions literally with every revision, and Skype woes are legendary. On a somewhat minor scale, there is a certain "minimal viable product" feel to VS Code. It lacks some very basic functionality like printing a file (!), and monthly updates show numerous basic improvements that (ideally) should have been there from the day one. It is annoying, because I have to review these changes every month to make sure I am not missing anything really important. There is also a debatable decision to put most functions into a "Command Palette" input box without having them duplicated in the main menu. So you have to know what to type; otherwise, well, bad luck. UI customization is quite limited, so third-party extensions also often have to resort to Command Palette entries only.

On Extensions

Given these numerous limitation of the basic system, it’s easy to see that the availability of extensions is the thing that makes VS Code a really versatile instrument. It seems that people invest a lot of effort into these extensions, so the chances of your problem to be addressed are quite high. As I said above, there is a reason to prefer fewer universal tools over a large set of specialized tools: it reduces cognitive load. This statement might seem contradictory to the basic tenet of Unix philosophy "make each program do one thing well". I am not sure about it: Unix tools tend to do orthogonal things, so it makes sense to keep them separate. When I edit text, I don’t really feel that spellchecking, for example, is a separate activity. Similarly, if I design a regular expression for my Python code, I don’t feel that having a separate regular expression editor/visualizer is desirable.

Summing up, I think that extensions should be considered an integral part of Visual Studio Code. You can’t really do much without them. Many extensions are developed by Microsoft, so they are a part of Visual Studio Code in a sense. It is also worth mentioning that extensions are synchronized across machines, so it is enough to setup them once and enable a "Settings Sync" option to configure them for the given user account. So, here is the basic language-independent stuff I use:

  • AsciiDoc. Edit and preview AsciiDoc documents. Using it right now to create this post.

  • Bookmarks. Ordinary bookmarks, like in any reasonable text editor except VS Code, where you need a third-party extension. There are similar other plugins, but this is the most popular one. Functionality is available via keyboard shortcuts, right-click, and Command Palette.

  • Hex Editor. There are better proper hex editors, of course, but I don’t edit hex often, so this extension seems sufficient.

  • Hg. As a long-time Mercurial user, I feel somewhat abandoned in the Git world of today. Fortunately, this extension makes VS Code’s "source control" capability Mercurial-compatible. Don’t really use it often, though, TortoiseHg is an old habit.

  • markdownlint. I use Markdown quite often for readme files and other simple documents. Markdown has a few subtle rules, for example, related to the use of trailing spaces and newlines. The "tinker until it is displayed correctly" approach is fragile, as different renderers may display the resulting document differently. This extension provides helpful real-time style feedback (linting), which improved my Markdown a lot.

  • Print. Yeah, a document printing capability. This extension is not the most popular one, but I like it includes a toolbar icon, so a document can be printed with a single button click.

  • Regex Workbench. A simple editor for regular expressions with all the basic capabilities one might imagine.

  • Shortcut Menu Bar. Adds a toolbar with buttons for a number of common operations. In a way, this approach seems to be against the principal VS Code UI design philosophy: a large toolbar gives VS Code a sort of pre-ribbon MS Office look. Thus, I enable just a couple of buttons.

  • Spell Right. A very nice multilingual spellchecker with autocorrection capabilties.

  • Sync Scroll. A somewhat esoteric and slightly buggy extension for simultaneous scrolling of split panels. Useful for reviewing file diffs, for example. Unfortunately, the "sync mode" can be enabled or disabled via Command Palette only, but I don’t use it often anyway.

  • Todo Tree. A great little extension that shows TODO, FIXME and other comment tags found in the open workspace. Makes these comments easily navigable.