3 ms·
Apologies if this is do-able in VSCode, but for me the killer feature of Emacs is that configuration is literally just running code. In VSCode, I don't think t
by cyrialize 3y ago
Apologies if this is do-able in VSCode, but for me the killer feature of Emacs is that configuration is literally just running code.
In VSCode, I don't think there's anything like "place code in this file, run it at startup, and code within this file can be present/applicable everywhere". Maybe you could do something as a plugin, but that is a big lift compared to Emacs.
For example, think about doing a "Hello World".
In Emacs, you just open init.el and place `(message "Hello World!")`.
In VSCode, you have to follow a whole set up for an extension [0].
[0]: https://code.visualstudio.com/api/get-started/your-first-extension https://code.visualstudio.com/api/get-started/your-first-ext...
- tom_ 3y agoThis is the best thing about it for me as well. You can experiment with M-: or the scratch buffer to figure out what exact bit of elisp needs to be invoked; then use defun in the scratch buffer to make an interactive function of it; then use M-x or a keyboard macro to test it repeatedly while you're fiddling around; then assign a shortcut and test that out too. Once you're done, you've got everything in the scratch buffer and/or M-: history to paste into your init.el. Worst case, you'll mess up your startup file and need maybe 2 or 3 restarts total to ensure that you've captured everything correctly. If you can do this in Visual Studio Code, it was not at all obvious how when I was looking. There's seemingly no way for you to add any code that executes in the editor's VM without literally restarting the process with your updated code in place. (Visual Studio suffers from a very similar problem.) 2 or 3 restarts is just the beginning! You'll need that many just to be sure you've got all the boilerplate in place.