
10 years of love for Emacs undone by a week of VSCode - Swizec
https://swizec.com/blog/vscode-better-editor-emacs/swizec/7921
======
pmoriarty
_" The feature that made me try VSCode for real. You can hover any function or
variable, press command, and see its definition in a little popup. Or jump
straight to the code."_

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.

~~~
likelynew
That was the exact thing that came in my mind first. Here 10 years might just
mean the date author first tried Emacs and not the time for which Emacs is the
primary editor.

~~~
platz
All those tags options require a gen tags file step that is completely
inadequate and cumbersome

~~~
pmoriarty
That step can be completely automated.

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.

~~~
melling
...or you could just use the editor that does what you need out of the box.

Yes, emacs is great but many people will go with less friction.

~~~
pmoriarty
_"...or you could just use the editor that does what you need out of the
box."_

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.

------
to3m
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.

~~~
ZenoArrow
> "where's the in-editor JS REPL"

Can use Code Runner for evaluating JS in a REPL...

[https://marketplace.visualstudio.com/items?itemName=formulah...](https://marketplace.visualstudio.com/items?itemName=formulahendry.code-
runner)

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...](https://code.visualstudio.com/docs/editor/integrated-terminal)

> "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
The 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.)

~~~
ZenoArrow
> "The org-mode reference is "rhetoric". That's the Latin for "#thatsthejoke"
> :)"

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.

~~~
to3m
The Code Runner looks like it just runs a script and puts the output in a
VSCode panel, which is not the same thing. VSCode is written in something that
compiles to Javascript, right? So, while you're running VSCode, there's a JS
VM that's running the VSCode code. So what I'm missing is a way to be able to
run your own code inside the same VM that the editor's code is running in,
giving it full access to all the objects and state that the editor's code is
in.

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.

------
sannysanoff
Author discovered "goto definition" in 2017??

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.

~~~
PuercoPop
They are implemented in Emacs as well. There is no meat in the article, no
proper comparison between Emacs and VSCode

------
josteink
Fellow Emacser here. I tried vscode too for a while.

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.

------
joaodlf
I used VSCode exclusively while building a Go project, a while ago.

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?

~~~
randallsquared
I dropped PHPStorm for VS Code as soon as I could. PHPStorm (and WebStorm)
just felt slow by comparison with VS Code, and that was mid-2016. Sometimes
upon opening a project, not for the first time, PHPStorm would just freeze
while my MBPro fan spooled up like it was going to take off. I say, "not for
the first time," because this same behavior on opening a medium-sized monorepo
was absurdly drawn out. When I was using it every day (in 2015) at a workplace
where everyone else also used it, opening PHPStorm was something I tried to do
only once a day, when I got to work, so that I could use that time to go get
breakfast while it struggled with indexing or whatever. That one behavior put
me off of Jetbrains products and sent me searching for something better over
and over, and it's something that VS Code never does. Of course, once in a
while Code struggles with individual files if they're more than a few thousand
lines, but it doesn't present as a speedbump I have to navigate every time I
open the editor, at least.

~~~
joaodlf
I have to admit, I open my IDEs maybe once a month (and only when a restart is
imposed in me), and while indexing can take a while, I don't get anywhere near
to the sort of issues you have, even on very, VERY, large codebases. Different
hardware, I guess. Although I can't help but think the situation should be
much worse under any Electron malarkey.

~~~
randallsquared
VS Code doesn’t seem to require indexing in the same way.

------
stevebmark
Indeed it's nice we have a free, open source _code_ editor that has true
intellisense out of the box. (And that isn't terrible, like Eclipse). It's a
good personal growth point realizing that you don't need to solve the problem
of figuring out which combination of plugins you integrate into your _text_
editor (like cscope or ctags), and start editing in a _code_ editor that has
solved this for you.

~~~
didibus
Honestly, Eclipse is pretty great actually. It does run faster then VSCode. It
just needs a better ux.

------
4lch3m1st
Funny, exactly the opposite happened to me. I have been using VSCode for C++
projects and, after discovering that it had very poor support for the Scheme
language, I was practically forced to try out Emacs. A few months messing with
it and some new lines on my .emacs file, I just had all my needs fullfilled by
it.

------
0xfaded
I once had a Java job which required me to use an IDE. What I noticed is that
I became dependent on the auto-lookup features and didn't really learn the
codebase until at least a year in.

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.

~~~
yodon
Yes, there was a time when I took pride in that too. Then I realized how much
more effectively I could use that cognitive capacity if I was applying it
where it was best used rather than where my tools forced me to spend it.

~~~
holydude
Any tool or technology requires an investment. It just depends on how much you
want to spend on it. You do not need to be an emacs guru to use emacs. Just
learn the basics,downloads some pkgs, use what other people already built for
you. Hell I never ever wrote a line of elisp but I am able to glue things
together so It does what I want.

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. )

~~~
platz
What if I don't _want_ to make that investment, because otherwise I have to
make 1000 investments for glue code projects

~~~
donovanm
That's quite an exaggeration, there's already written packages in emacs for
lots of programming languages. Just need to add the package to your config.

------
jimnotgym
I am an Atom user. Coding isn't my main job, but it is part of it. I really
appreciate how cool VIM is and I once spent an afternoon trying various plug-
ins and getting something to code with. At least now I can edit files on our
Solaris machine and know how to save and exit.

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...

------
danellis
Is there a name for the phenomenon where someone thinks something pedestrian
is amazing simply because they're ignorant of what else is available?

------
phoe-krk

        You can hover any function or variable, press command, and see its definition in a little popup. Or jump straight to the code.
    

SLIME for Common Lisp have had it for a much longer time, M-. works well
enough in it.

~~~
lispm
M-. is the key-command to locate source code in Emacs since the early days.

------
uiri
That little popup is basically just cscope. It isn't unique to VS/VSCode or
even any specific IDE/editor.

~~~
na85
Isn't cscope only for C/C++?

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.

~~~
eighthnate
> I hate writing C# or Java in emacs because there's no intellisense/code
> completion.

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.

------
SteveJS
As I write from a Mac that has VSCode running in the background, I'm rooting
for it. But then, I'm biased. The VScode team started as a sister team to the
Chakra javascript engine team, and I worked on Chakra for a few years. The
lead architect for Chakra very early on implemented an emacs editor in IE6
with the old javascript engine just to prove it was possible. It's cool to see
the vision that was so clearly articulated years ago coming to fruition.

------
geogriffin
are you sure that little popup is not implemented in some emacs package? i get
those little popups when working in edts-mode with erlang..

~~~
IronBacon
I would say clippy.el, and if Emacs is compiled with GTK+ support, it can
display a "graphical" tooltip instead of a text one.

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).

------
georgecarlin
You used emacs for 10 years and never used cscope?

~~~
coldtea
Since he wants that feature to work for Javascript, cscope is irrelevant
anyway.

~~~
MetaDark
Well if he wanted code navigation for JavaScript he could have used tern. It
also integrates nicely with company for auto-completion.

~~~
josteink
Or tide, which uses the typescript tsserver-backend for all its code-analysis.

Gives you navigation, refactoring, completion, eldoc etc. Basicslly JS on
steroids.

------
kyberias
Let's now all reference our own favourite IDE that can also go to function
definition with one click.

------
zitterbewegung
You can configure emacs to have practically all the features of VSCode. The
problem is that getting there has a high burden to get there .

I was thinking of making a VSCode clone setup for emacs .

------
mattdennewitz
amazing what can happen when one invests oneself for more than 18 minutes.
anyway, welcome to the party.

------
pmarreck
This all said... I think I could really use an in-depth "guided tour of
VSCode"

------
baldfat
I have used VIM since my Amiga. I use VS Code most of the time.

------
modzu
starting to think ms has an army of interns whos job is to make ms look
"cool"...

~~~
ZenoArrow
The killer feature the author points out is something pretty much all modern
IDEs have. If you thought the feature was "cool" then I'd recommend picking up
any commonly used IDE, it doesn't have to be one from MS.

~~~
modzu
i do not mean the feature -- i mean why the hell is it on hackernews front
page?? (a joke i hope)

~~~
ZenoArrow
Do you have a problem with Microsoft?

------
holydude
Author instead of looking how to solve this particular issue in emacs threw
everything away and tried a glorified browser masked as IDE :))

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.

~~~
terminalcommand
IMHO out of the box experience does not matter that much from a point-on,
because configuring emacs with an existing configuration is very easy. You
just need to save your .emacs.d folder and every config you've accumulated
over years is there.

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")
    

(I see now that there are some prepared configs such as
[https://github.com/purcell/emacs.d](https://github.com/purcell/emacs.d))

------
rryan
It's obvious the topic of this post is strategic -- it will drive traffic
which helps him sell his content.

------
anothertraveler
The best editor is the one you know how to use. This is sage advice!

