3 ms·
Stuff seems to be very easy to get working in VSCode, whereas almost everything is a bit of a faff to set up in Emacs. Getting decent Go support in VSCode took
by to3m 9y ago
Stuff seems to be very easy to get working in VSCode, whereas almost everything is a bit of a faff to set up in Emacs. Getting decent Go support in VSCode took about 1 minute, for example, and the only problem I've found with it is that now I've got to use Go. Emacs on the other hand... well, I haven't even bothered. It's almost certainly going to be a complete bind. (And even if it isn't, my statement is worded in such a way that I'm actually still right.)
Once you've been using VSCode for a while, though, you'll start to wonder just why you can't move that stupid sidebar to some other place on the screen.
Or maybe you'll wonder why you can't see its individual components in different windows. Why are they all stuck as like tabs of the same panel?
Come to think of it, why can you only split the editing window twice?
And considering it's all driven off a dynamic language, how come there's so much damn boilerplate when it comes to writing an extension? And where's the in-editor JS REPL akin to M-: or the scratch buffer? (Actually, now I've even asked that question, I'm sure I've just missed something obvious, because there has to be one, and it must be there.)
Don't even get me started on how to share configs between multiple systems... (there's an addon that'll upload them to gists but there doesn't seem to be any way to have system-specific configs, something that Emacs solves inherently because its config files are just Lisp code)
Also, VSCode doesn't work properly with my favourite font on Windows.
And I'm not going to mention org-mode.
- Karrot_Kream 9y agoI've used emacs for a long time (13 years now I think) and while I've been super impressed at the progress emacs has made (MELPA, helm, etc) it continues to be cludgey to support other languages. That said, Go is actually one of the best supported languages because of the CLI tooling it offers. Company mode also completed Golang super well and with flycheck it all works pretty much out of the box.
- tetraodonpuffer 9y agoI suggest also adding gometalinter[1] and its flycheck support [2], which also works quite well and allows you to have more linters available [1] https://github.com/alecthomas/gometalinter https://github.com/alecthomas/gometalinter [2] https://github.com/favadi/flycheck-gometalinter https://github.com/favadi/flycheck-gometalinter
- ZenoArrow 9y ago> "where's the in-editor JS REPL" Can use Code Runner for evaluating JS in a REPL... https://marketplace.visualstudio.com/items?itemName=formulahendry.code-runner https://marketplace.visualstudio.com/items?itemName=formulah... Can also use the Shell Arguments feature of the Integrated Terminal to start up a JS REPL when opening a new terminal window... https://code.visualstudio.com/docs/editor/integrated-terminal https://code.visualstudio.com/docs/editor/integrated-termina... > "there doesn't seem to be any way to have system-specific configs" Just use Git, and only clone the repos for the system settings you're interested in using. So, if you have a Git repo for VS Code settings on PC 1, don't clone it on PC 2. Not that hard is it. > "And I'm not going to mention org-mode." I think you just did. It looks like someone wanted to implement it in VS Code ( https://github.com/jsonreeder/vscode-org-mode https://github.com/jsonreeder/vscode-org-mode ) but there were issues holding it back from being implemented fully, such as: https://github.com/Microsoft/vscode/issues/3422 https://github.com/Microsoft/vscode/issues/3422
- to3m 9y agoThe org-mode reference is "rhetoric". That's the Latin for "#thatsthejoke" :) Regarding the REPL - what I mean is, run a snippet that executes in the context of the editor. Like, in emacs, you can execute ``(defun fred () (interactive) (insert "fred"))'' from the scratch buffer, and now you've got a new editor command: fred. Run it with M-x (the closest Emacs analogue to the Command Palette). Bind it to a key, maybe: ``(global-set-key (kbd "<f6>") 'fred)''. Good for prototyping, debugging addons, or just writing quick one-off things. And as for Git, I don't really understand the suggestion. I have a Git repo for Emacs settings that works on all my PCs: Linux, OS X (terminal), OS X (GUI), Windows (non-work), Windows (work). If there's anything that needs to be different on one or the other, I just do ``(when (tom--is-osx) ...stuff...)'' or whatever. tom--is-osx is a function that's something like ``(defun tom--is-osx () (eq system-type 'darwin))'', and so on for the other systems I use. I check for my work PC by examining the hostname. For VSCode, on the other hand, there's only one settings.json (and it's right out of the way, in some fiddly folder structure that's laid out like there's no real user-serviceable parts inside, which gives me pause - but that's a separate issue). In my case, most of it wants to be the same on every system. Some bits want to be different. I'd also like my plugins list to be synced as well. Doesn't seem to be any good support for that either. (This stuff is easy to do with Emacs, because Emacs doesn't have a settings file per se, just a file with Lisp commands in it that, when run, leave the system in the desired state. So you can have ifs, along with anything else you like, because it's just code.)
- TimTheTinker 9y agoI completely identify with your frustration over the lack of support for multiple windows. <political-request> Anyone else who shares that frustration, please vote here if you get a chance: https://github.com/Microsoft/vscode/issues/10121 https://github.com/Microsoft/vscode/issues/10121 </political-request>