Keep VS Code from Becoming an IDE
dev.to
dev.to
VS Code is architected in a way where extensions are not eagerly activated by default. Each extension can declare a list of activation events, such as e.g. opening a file of a certain language, invoking a specific command, starting debugging, etc. See for example the quite long list of activation events for our built-in TypeScript extension [1].
However, we also offer an activation event called ' * ', which means an extension can ask to be activated on startup. Some over-eager extensions might be using ' * ' to start up as soon as you open a VS Code window. You can find those extensions at any time using F1 > Developer: Show Running Extensions which will show the subset of extensions running at any time, and if they were activated on startup or not.
Moreover, that view can guide you into profiling the extension host and can help you easily figure out if any extension is consuming extensive CPU. This was added quite recently [2].
[1] https://github.com/Microsoft/vscode/blob/1638acdd62d94bc4d99...
[2] https://code.visualstudio.com/updates/v1_19#_running-extensi...
I wonder if there also is a place we can view the activation events of an extension from within VS code. If there isn't, I guess I can always find that info out from the hopefully available repository of the extensions.
I really, really, hate this often touted false dichotomy, and the smug sense of superiority it engenders. Some people just use the right tool for the right job. If I'm cranking out some bash scripts, of course I'll pop open Vim. If I need to edit a CSS file real quick, I'll open up Sublime. If I'm writing a new C# class to integrate with some large codebase based on a complex library, for the love of god give me Visual Studio. If I'm debugging a JSP stack trace in Java/Spring, I would hate my life without IntelliJ. People who "personally identify" with their preferred tools and use/advocate them zealously are idiots with narrow experience.
emacs and vim have always had self imposed limitations by requiring that all of the core features work on a remote terminal (with mouse being an after-thought/optional extra). Sublime, VS Code, and even Visual Studio have no such limitation so I'll keep using them.
Each to their own of course. :)
https://github.com/terryma/vim-multiple-cursors
I don't use them because if I want to change text in multiple places, you can highlight the lines where you want to change it, for example the current line to line 57 would be: V57G.
Then to change `foo` to `bar` type: :s/foo/bar/g and the replacements will take place within the selected range. If you only want to change some of them add a c on the end of the command.
Column selections: `ctrl-v`.
I'm not sure what kind of live feedback you mean, but Vim gives multiple forms of feedback, depending on what plugins are installed.
And in case you're not aware, you can install gvim to give vim somewhat of a GUI.
As a developer I'm not sitting down an typing constantly like some bad Hollywood "hacker" montage, or a court reporter. So preemptively optimizing a tiny subset of my workflow really doesn't offer much value.
Contrast that with something like Chrome Debugging for VS Code[0] or GitLens[1] that are fitting into what I actually spend a lot of time doing, therefore improving productivity. If my typing was 50% faster my overall productivity would be maybe 5% better, because that just isn't a bottleneck.
I feel like the vim/emacs crowd experiences professional programming VERY differently to anywhere I've worked. Myself nor any of my colleagues are just type-type-type. I spend more time reading and writing OneNote documentation files (specs, etc) than I do writing code. I spend more time in meetings than I do writing code. I spend more time debugging and testing than I do writing code.
[0] https://code.visualstudio.com/blogs/2017/12/20/chrome-debugg...
For me, at least, learning vim has the same kind of benefit. It's not about getting characters into the editor faster, it's about being able to manipulate text without having to think about it.
It's the unglorious part of our work, the part that we're paid far too much for, since you can't quite ask a secretary to do it.
So, it's seldomly acknowledged that we do this stuff, but it's not even particularly uncommon with database and GUI code often being mostly that.
There you are mostly bottlenecked by your typing speed, not by how much you need to think.
As for your argument that typing speed is not the most important thing about a text editor, that it's its tooling instead: Emacs has a thousand features beside text editing, while vim has a thousand extensions to add those features. I'm sure, if you actually used one of these text editors you'd just as well have anecdotes of things you feel are important which you don't have on the other platforms.
Off-topic: OneNote is probably going the way of the Dodo by the way. Microsoft Office 2019 and onwards will not ship with it. You can comtinue to use OneNote 2016 for a while still, but it's eventually not going to get security patches anymore.
Microsoft does provide what they consider a continuation as a UWP app, but as it stands you can't use that without uploading all your notes to Microsoft's servers, so hardly usable in a company with any sort of sense for confidentiality and data protection.
Also, both emacs and vim have non-terminal versions. I would imagine those are more mouse-friendly, but I have not tried them.
[1] For years my workstation mouse was a trackball in a drawer
The mouse is probably an afterthought because using the mouse is significantly slower than the keyboard commands.
When you have enough commands in muscle memory and use it as designed, it's almost like a telepathic communication with the computer.
Everyone has their own preferences though.
It took a little bit of setup and a whole lot of learning, but I'm already reaping the rewards. Text editing is straight up faster, Org mode is really cool, and Magit is probably one of the best git clients I've used.
Also, for a piece of software that came from the 70's (?), the Mac port of Emacs actually looks and feels pretty modern.
It does still have some quirks owing to its provenance but if you turn off the toolbars and choose a decent font it looks as good as anything else. Emacs is a lifelong journey. It's like playing a musical instrument. The possibilities are endless and you'll never reach the end but whatever stage you're at you'll still have fun using it.
There are still plenty of other extensions that provide language-specific features that aren't language support, and those will end up getting loaded every time if they aren't deactivated. I find it's still useful to keep those installed and disabled by default, and only enable them for appropriate workspaces. It does help with maintaining Code's great performance.
Like when I'm working with Django(Python) I only enable my Python Extension Pack(has Jinja Templating & Django Snippets Support) whereas I only enable Node Extension Pack while writing Javascript.
- Prettier
- Regex preview
Look at the likes of Eclipse, not using Electron and way slower, while offering a marginal increase in functionality compared to a customized VS Code with plugins. Also, would you spend 5 hours each day in front of a Winforms or Awt based usually ugly-ass editor?
The only negative side of going with Electron in the VS Code case is the size increment that comes from bundling the chrome engine.