I like VS Code. It runs on Linux. It’s fast enough for an Electron app. It’s extensible. It doesn’t try to push me toward Microsoft technologies. Most important to me, it feels like the people who build it also use it.
A great example of that last point is keyboard focus. In VS Code, it’s always where it should be. Many poorly implemented apps present a form for you to fill out, and then do nothing when you start typing. That’s because the developer forgot to set focus to the first field of the form, like that guy at Subway who asks what you’d like to order and then stops listening while you’re speaking. It’s rare for VS Code to get this wrong. When you type, the characters go where they’re supposed to go.
Another example is stable positioning of UI action elements. If you do a global search and replace on a project, VS Code’s find-next and replace buttons stay in the same place on the screen, rather than floating along with the search results. That’s important for the review-act-review-act workflow; you want to inspect what you’re about to replace, then click without having to move your eyes. Web apps, in particular, get this wrong all the time. You want to go to page two, so you click the next-page button. Then you want to go to page three, so you click again. Surprise! You just clicked an ad because page 3’s contents were a different vertical size from page 2’s contents, so your click missed the button. (I know, I know, this is often not negligence, but rather intentional design to defraud advertisers with fake clicks.) VS Code’s no-look clicks are a refreshing contrast.
I’ve been using VS Code daily for about a year. I’ve built up a lot of muscle memory and discovered useful nooks and crannies. I’d like to get into the habit of documenting them here, so others can find them.
Today’s tip: opening a file instead of a diff. This starts with a bit of a VS Code criticism. The Source Control view is very useful, but it’s modal. You can’t see both your project explorer view and the source view at the same time. (I’m sure you actually can, but I prefer the default window layout, so I can’t.) The Source Control view looks a lot like the project view, so it’s easy to use it to bring up the file you want to see if you happen to be in the wrong view. But it actually brings up a diff view, not the regular file/editor view. This is usually OK, but it falls over when you start typing. It leads to a moment of frustration where I have to close the file’s diff view, then go find or open the editor view. What I really want is a way to switch from the diff view to the file view.
I haven’t found that direct switch yet, but I have a two-step action, and that’s today’s tip. Right-click the diff view’s tab. “Reveal in Explorer View.” Press Enter. You’re now where you wanted to be. This works because the menu item highlights the file in the explorer view, and sets focus to it, so that the Enter does the natural thing of opening the highlighted file.
If “Reveal in Explorer View” had a default keyboard shortcut, then I could commit it to muscle memory, and it would be perfect. I could create one, but I haven’t had a lot of luck picking and then memorizing custom keyboard shortcuts.