10 years of love for Emacs undone by a week of VSCode
swizec.com
swizec.com
Are you fucking kidding me? This is the amazing feature that made this guy "admit VSCode is a better editor than Emacs"?
etags, gtags, ctags, universal-ctags, rtags. It really doesn't take much searching to run in those or their integration with Emacs. It's difficult to imagine this guy using Emacs for 10 years and never becoming aware of any of them.
Not to mention the offhand dismissal of the value of the rest of Emacs because of some single feature (which Emacs doesn't actually lack). Everyone's entitled to their opinion, I guess.
You could also use something like the dumb-jump package which doesn't even require a tags file. It's not perfect, but it suits the needs of a lot of people.
Yes, emacs is great but many people will go with less friction.
If your needs are simple enough that you don't need Emacs, more power to you.
Some people are happy programming in Notepad because it does all they need -- or all they think they need.
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.
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.
[1] https://github.com/alecthomas/gometalinter [2] https://github.com/favadi/flycheck-gometalinter
Can use Code Runner for evaluating JS in a REPL...
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-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 ) but there were issues holding it back from being implemented fully, such as:
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.)
I got what you were doing with it (suggesting it in a jokey way as if it wouldn't be fair to even bring it up), I was just using it as an opening to discuss alternative org-mode implementations. Emacs may have the canonical one, but it's not like it's impossible to implement elsewhere.
> "Regarding the REPL - what I mean is, run a snippet that executes in the context of the editor"
Is that not covered by the Code Runner extension I suggested earlier?
> "And as for Git, I don't really understand the suggestion."
Multiple Git repos, each one covering different system settings. In other words, if you work across two PCs, one Git repo for PC 1, another Git repo for PC 2. Alternatively, you could organise it in the same repo under different branches. If you know Git you'll know what I'm suggesting is trivially easy.
You can use this to write ad-hoc extensions that disappear when you quit, or just experiment with the extension functionality. This is typically how you start and then iterate on extensions in Emacs.
<political-request> Anyone else who shares that frustration, please vote here if you get a chance: https://github.com/Microsoft/vscode/issues/10121 </political-request>
it will take another 10 years for him to discover that all that code understanding (even more precise!) and 10 times bigger load of useful features were already implemented in WebStorm, for ages.
Ok, anyway.
It’s amazingly appealing. Lots of things just works out of the box. For an electron-app it’s surprisingly responsive. Clearly good engineering. And to think it’s a cross platform, open-source project made by Microsoft!
That said, as an Emacser, I just notice things everywhere where I want/need to tweak and change things slightly to fit my work-flow.
But then you can’t. Not at least without a full rebuild-cycle. So that doesn’t really work.
After meeting a few issues like that, I was quickly back to Emacs.
It’s not as visually fancy or OOB ready. But it has a select few, powerful primitives and full access to adapt everything those provides to suit how you work.
A little bit of fancy is nothing against that kind of power, but I can definitely see how this eats market-share from other editors in the beginner-segment.
At the time support for this language was mostly offered via Vim and VSCode - Vim is a love/hate thing for me, so I decided to jump in with the cool kids and play with VSCode.
It was pretty great, the Go support was amazing, I was getting the productivity I needed. And then my project grew. And then my VSCode memory usage grew even more. It became clear to me just how bad this Electron deal is.
Maybe one day Electron/JS will grow in a direction that makes any sense when it comes to performance, until then you're better off just using other software - I absolutely recommend anything by Jetbrains, the license is affordable and extremely worth it, they now have an IDE for Go (not fully out but you can grab a EAP that works GREAT). I can't even begin to understand some of these blog posts - People seem to just now be discovering things like GoToDef, syntax checkers, auto tooling... Really? From Eclipse, to Netbeans, to the now amazing software provided by Jetbrains - None of those features are new. I like to try new editors/ides, but if they don't offer these things out of the box (or without minimal dependency management), why even use them? The feeling of lightness that your hardware disagrees with?
I use vim, and whenever I need definitions from other parts of the code base I put them all up in multiple panes or tabs. Its not as immediate as the pop ups, but it forces me to go look at that part of the code base. I find I learn the relevant parts of the code very quickly and even remember the most common definitions.
You don't. You do it with Vim and a language plugin. The support across languages isn't great, but this is what the LSP is helping fix.
Which, it's important to note, was designed for VS Code.
But you are right if a tool is just as good in its default configuration then it's harder to justify the investments to learn another one.
On the other hand Emacs has been here for dozens of years and it still mostly works and behaves the same. )
It is great if you don’t work on the codebase enough to justify learning it completely.
On the other hand I installed Atom and started coding right away. It had a sensible font and colour scheme, a nice file explorer and tab indents four-spaces. But best of all, it does this on Python, SQL, Markdown, HTML, and all the other things I have to dabble in with zero config. Yes it uses a fair bit of memory (I use an ancient Thinkpad T410 with 4GB ram and am doing OK). It also sucks at opening really big files, like log files, but cat, grep, head and tail deal with those anyway. But apart from that it is great. If I could be bothered I would try VScode again to do a comparison, but I have no real need. If my projects ever run to hundreds of files I will get Intellij.
HN loves Electron...
You can hover any function or variable, press command, and see its definition in a little popup. Or jump straight to the code.
I hate writing C# or Java in emacs because there's no intellisense/code completion. There exist projects like omnisharp but I've never been able to get it to work successfully.
Agreed. The quality of the IDE/tools is such a huge factor in the quality of one's experience writing code.
Can't imagine writing C# outside of Visual Studio or VSCode. Can't imagine writing Java outside of Eclipse.
Can't imagine using anything but vim or emacs for academic coding ( Standard ML, lisp, c, etc ).
But it might be because I'm just used to coding in these IDEs/editors for these particular languages.
Edit: I'm wrong, clippy describe a function in a tooltip, it doesn't show the definition, one should extend it to use something like xref-find-definition (M-.) for the Lisp mode (and for Elisp there is the elisp-slime-nav package).
Gives you navigation, refactoring, completion, eldoc etc. Basicslly JS on steroids.
I was thinking of making a VSCode clone setup for emacs .
What I have to acknowledge though is that out of the box experience of VScode is like a billion times better than what you can get with emacs or spacemas.
I am not sure about extensibility but I think in the long run VSCode/Atom will greatly benefit from using a language that's just simply more popular.
I'll probably stop using emacs when people stop developing great modes for it. I still hate that out of the box experience (even for installing and activating the pkgs) on emacs is a thing from the past.
The nice thing about emacs is the extensibility, you can very easily write your own modules load it etc. I understand the same argument could be made for VS Code, but I think emacs is here to stay, because Electron can never be as responsive as a native application.
On the other hand it's true that installing emacs packages and getting them working is cumbersome. Maybe, as a community, we need to prepare modular dot files. For example, are you a Go developer, go install Go Emacs. Or are you a web developer Go install Web Emacs etc. Having a set of prewritten configs would benefit Emacs's popularity.
For example my init.el in .emacs.d consists of a couple of lines loading my modules:
(package-initialize)
(load-file "~/.emacs.d/melpa.el")
(load-file "~/.emacs.d/golang.el")
(load-file "~/.emacs.d/readability.el")