10 years of love for Emacs undone by a week of VSCode(swizec.com)
swizec.com
10 years of love for Emacs undone by a week of VSCode
https://swizec.com/blog/vscode-better-editor-emacs/swizec/7921
71 comments
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.
All those tags options require a gen tags file step that is completely inadequate and cumbersome
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.
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.
...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.
Yes, emacs is great but many people will go with less friction.
"...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.
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.
haha, I bet his mind will be blown by Eclipse/IntelliJ then.
ah, but you have to understand, "muh ide sucks!!11! use vim!!1!!"
IDEs are great but need to work on lowering the bar for writing plugins / extending behavior. Say what you will the bar to make emacs do what you want is significantly lower than writing a plugin for Eclipse / Clion / Visual Studio.
Ok, but what is even more amazing is he didn't realise that IDEs have that feature. What did he think they did, just syntax highlighting?
Right, but considering this guy made a "reality" video featuring him totally pointlessly walking around outside, this level ignorance seems par for the course. The worst part is that this type of pathetic behaviour will no doubt land him a keynote at some "exciting" conference.
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.
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.
> "where's the in-editor JS REPL"
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:
https://github.com/Microsoft/vscode/issues/3422
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:
https://github.com/Microsoft/vscode/issues/3422
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.)
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.)
> "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.
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.
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.
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.
I 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 </political-request>
<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>
I'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.
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.
I 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 [2] https://github.com/favadi/flycheck-gometalinter
[1] https://github.com/alecthomas/gometalinter [2] https://github.com/favadi/flycheck-gometalinter
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.
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.
They are implemented in Emacs as well. There is no meat in the article, no proper comparison between Emacs and VSCode
It's a bit better than that as you can edit the code in the preview window too, scroll around etc. It is an essential feature of any ide but made even better.
+1 for the *storm love
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.
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.
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?
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 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.
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.
VS Code doesn’t seem to require indexing in the same way.
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.
Honestly, Eclipse is pretty great actually. It does run faster then VSCode. It just needs a better ux.
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.
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.
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.
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.
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. )
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. )
The flipside is, I can change a method name across 100 files with 1 click in IntelliJ, and be confident that it did not blow up the world. How are you doing that with VIM, grep and then editing 100 files at once? No thanks.
> How are you doing that with VIM, grep and then editing 100 files at once?
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.
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.
> 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.
Which, it's important to note, was designed for VS Code.
Many IDE features (e.g. code completion) excel at letting you use code that you don’t understand well, you can jut jump right in and get something to work. But ya, it’s a just-in-time mechanism that can be used as a crutch for actually learning the abstractions of the code you are working on.
It is great if you don’t work on the codebase enough to justify learning it completely.
It is great if you don’t work on the codebase enough to justify learning it completely.
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...
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...
Is there a name for the phenomenon where someone thinks something pedestrian is amazing simply because they're ignorant of what else is available?
You can hover any function or variable, press command, and see its definition in a little popup. Or jump straight to the code.
M-. is the key-command to locate source code in Emacs since the early days.
[deleted]
That little popup is basically just cscope. It isn't unique to VS/VSCode or even any specific IDE/editor.
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.
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.
> 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.
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.
There's cscope, ctags, gtags, etags, rtags. All but cscope can handle more than just C and C++.
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.
[deleted]
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..
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).
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).
You used emacs for 10 years and never used cscope?
Since he wants that feature to work for Javascript, cscope is irrelevant anyway.
Well if he wanted code navigation for JavaScript he could have used tern. It also integrates nicely with company for auto-completion.
Or tide, which uses the typescript tsserver-backend for all its code-analysis.
Gives you navigation, refactoring, completion, eldoc etc. Basicslly JS on steroids.
Gives you navigation, refactoring, completion, eldoc etc. Basicslly JS on steroids.
cscope may be irrelevant, but ctags/etags has support for JS (and other languages that would be relevant for web developers, like HTML, PHP, Python, Ruby, SQL, ...).
Let's now all reference our own favourite IDE that can also go to function definition with one click.
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 .
I was thinking of making a VSCode clone setup for emacs .
amazing what can happen when one invests oneself for more than 18 minutes. anyway, welcome to the party.
This all said... I think I could really use an in-depth "guided tour of VSCode"
I have used VIM since my Amiga. I use VS Code most of the time.
starting to think ms has an army of interns whos job is to make ms look "cool"...
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.
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.
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.
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:
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")
It's obvious the topic of this post is strategic -- it will drive traffic which helps him sell his content.
The best editor is the one you know how to use. This is sage advice!
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.