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].
VS code sometimes performs better than VS. Can you elaborate on the reasons? Are there plans to migrate some optimizations or architectural lessons to VS?
Not a VSCode developer, but I imagine VS and VSCode are so completely different under the hood that performances comparisons between the two are not very useful. Not only are they architecturally completely separate animals, but VS probably has a lot of legacy baggage that needs to stay for backwards compatibility, which VSCode lacks.
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.
Hovering over the activation time will show the reason the extension is active. e.g. "Activated because you opened a javascript file", "Activated on start-up", etc.
It could do the opposite too. When a loaded extension is not used for some time (maybe the user switched to an project with a different language), so there is no active code depending on it then it should unload it to free up resources.
F1 doesn't seem to work for me on macOS (could be my non-Apple keyboard), but I see that the command palette also gives access to Show Running Extensions - very cool!
I'm sorry but this headline doesn't reflect the content of the article. (The linked article has the same headline.) The article is more about enabling VS Code extentions by workspace in order to keep VS Code fast. The current headline strikes me as clickbait.
>Some people like a big, heavy, comfy IDE. Some people like a light, zippy, relatively simple text editor and a terminal window. And some people like Emacs. We don't talk about them. (I'm joking, I'm sorry, I couldn't resist.) I'm part of the zippy editor/terminal group.
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.
On the other side, as a person that prefers keyboard control[1], I find many GUI editors to treat my keyboard as second-class, requiring the mouse to do basic operations, such as setting preferences, or enabling plugins. I would welcome efforts to bridge this gap.
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
Exactly this. Vim key shortcuts are truly awesome, but most of the times, mouse selection is just so superior, specially now with multicursors, column selections, and live feedback.
Whilst I'm unsure about multicursors, everything you've stated is possible with different visual selection modes. I think the biggest problem vim has is discoverability rather than direct ease of use or lack of functionality.
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.
That is most probably with a plugin; there are a number of plugins for vim that provide varying amounts of multicursor support. I haven't found one yet, though, that provides the amount of integration and speed that sublime text's multicursor feature gives; in my experience, the relevant vim plugins work mostly and are slow.
Emacs was designed with the mouse in mind, you can get pretty far just using the toolbar and menu items like you normally would. My understanding is that Emacs users don't typically work in a shell, they use the GUI application.
Source on that? While Emacs has pretty good mouse support these days, that wasn't always the case. I'd be surprised if pre-19 versions were mouseable at all.
Anyone not using a space-cadet or Symbolics keyboard could have remapped the mouse buttons to Ctrl and Meta to avoid Emacs pinky, but I still find it hard to believe that GNUmacs prior to the rise of Lucid/XEmacs had any real mouse support at all.
I don't think the keyboard could be described as a limitation. It gives such precise control over editing that you can look at a file and then perform complex edits without looking at the screen.
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.
A lot of people overlook that the real power of Emacs is that it is in reality just a huge Lisp interpreter which got some text-editor functionality builtin. Once you understand that, and know some Lisp, there are almost no limits in what you can do. It is super simple to get the documentation for everything and it is often quite easy to extend Emacs's behavior in the way I would like it to behave.
It's not just due to wanting to function on a remote terminal. You also have your hands on your keyboard while typing, so taking them off from there to your mouse and back to your keys will almost always cost you more time than doing it with keyboard shortcuts.
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.
And I think, you're not entirely honest about your work. More often than we'd like, we do just type in multiple variations of the same boilerplate code.
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.
Would you agree that touch-typing is a useful (or even necessary) skill for a programmer? I'd say it is, because it allows you to type without having to interrupt your thoughts with the process of finding where each key is.
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.
The mouse is the caveman interface. You can point and you can grunt. The keyboard allows you to use language. What on earth are you doing with your mouse?
It's faster with the keyboard because your hands don't leave the keyboard. There are so many ways to jump around quickly with the keyboard. In emacs I just use searching to jump around. Selecting is easy once you've learnt to navigate. The keyboard is an instrument you can get really good at using. You can't get good at the mouse. You're as good as you'll ever get already.
I'm fairly comfortable with VSCode and PyCharm, and recently started trying out Emacs for personal projects. I am pretty blown away by how pleasant the experience was.
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.
The first time I ever opened emacs it didn't have anti-aliased fonts. I shuddered and closed it immediately. At the time I was looking to learn a serious text editor so I turned to vim because gvim actually did have nice fonts. I struggled with that for a little while before discovering that emacs had just improved on the font front. Emacs made so much more sense and I kind of fell in love with it.
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.
It's like the old joke to the effect that most non-UNIX operating systems basically are just trying to reinvent UNIX as if it didn't exist already. These modern extendable editors like Atom and VSCode seem to be trying to reinvent Emacs.
I don't know anything about how VS Code is architected, but surely if language support extensions are such a drag on performance, the plugin API has some way to load them dynamically only when a project of the relevant type is opened, right? Or does it really load every conceivable language plugin you have installed into memory whenever you open a scratch file in VS Code?
Apparently that is indeed what happens, but VS Code still needs to load each active plugin's manifest and prepare hooks for when it'll be loaded. Still nowhere as bad as actually loading them all.
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.
Isn't VS Code (without any extension installed) already an IDE? As far as I know, I cannot disable the integrated NodeJS debugger or the integrated terminal for example.
Except there's no real definition of what an IDE is, just a general gut feeling that we mostly agree on. VS Code is one of the things that people don't agree on, however, so some will say it is and some will say it isn't.
This is why I use two. I use Sublime for my "should always be fast" because...it's always insanely fast but then use VS Code for more code-like things.
One can also install only an "Extension Pack" for a specific language/framework on VSCode and enable the only extension pack (in stead of going through each extension and disabling them) that he/she needs to work with at the moment.
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.
I always struggle with extensions. Often I just want to go completely extension free (as I do with Vim and Emacs). But some extensions are too good. A few that come to mind for VS Code are:
How much of that is a startup issue? My IDE sessions (VS, Eclipse, etc.) usually last several days but then I'm still using a workstation 90% of the time.
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.
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...