Is it? What area are you in? In my hobbyist, college, and industry experience I've never seen anyone use emacs for anything. I have seen Vim (or at least vim bindings) a few times, but I only know of emacs from older unix discussions online.
Edit: Looking through stack overflow developer surveys, emacs use is in 16th place for editor popularity at ~4.5% usage, but has stayed close to that number for years.
But the short summary is that most people use it for the various functions an IDE provides. The major difference between Emcs and other IDEs (VSCode, IntelliJ, ...) is that (a) it's often a little harder to get functionality that is provided out-of-the-box by another IDE, but (b) it's much easier (in some cases, infinitely easier) to implement workflows or functionality not already implemented by said IDE.
As an example, I often run snippets of code and want to insert the result directly beneath the code in question (similar to Jupyter in Python, but for any language, in plain text, directly in my editor). A trivial amount of Emacs Lisp gave me that with minimal effort.
If you like to have nearly absolute control of your editing experience, Emacs might be interesting to you. For most people starting out, who just want to get hacking on some code as quickly as possible, it is perhaps not the best fit.
- 2019: https://insights.stackoverflow.com/survey/2019#development-e...
- 2018: https://insights.stackoverflow.com/survey/2018#development-e...
- 2017: https://insights.stackoverflow.com/survey/2017#technology-_-...
- 2016: https://insights.stackoverflow.com/survey/2016#technology-de...
- 2015: https://insights.stackoverflow.com/survey/2015#tech-editor
What's really amazing is vscode just appearing out of nowhere (7% in 2016, 35% in 2018). Blindsiding everyone. Cross platform, excellent to good enough UI/UX (very much inspired by Sublime Text but free), easily extensible in a widely available (and widely taught) language. For better or for worse.
Never understood why other editors, like ST, didn't give more UI options (checkboxes, buttons, dropdowns, a canvas, etc) to plugin authors. Consider how clunky a lot of plugin interactions with limited UI widgets available to them are.
But even if other editors started giving more freedom to design your plugin with more widgets etc, they could never beat the freedom HTML/CSS gives.
The second huge advantage of VSC: Microsoft behind it updating it non-stop. TextMate stalled, ST seems abandoned for long stretches of time (and it's not like we "already solved code-editing, what more you want") because of lack of manpower, etc.
The third advantage of VSC: first-class support for plugins, with "package manager" and storage built-in: plugin discovery, install, uninstall, enable/disable, configure, are all a click away. ST has this too, but not as refined as VSC, but more like a tacked-on text-based experience.
Two more advantages of VSC:
- remote development tools (MS). Code in your laptop, run/debug in SSH/Docker/WSL environment.
- automatically saved/synced preferences. This came in in this release.
I'm not in favor of Electron apps over native. But VSC is really that good.
The issue I had with Emacs is that while could get it to do anything, often it took a lot of time. I would often end up spending an entire afternoon or Sunday tinkering with my config to get set up to develop in a new language. Whe I adopted VSCode it took about 20 minutes - install a plug in, set some config. I had a better setup for Elixir in a text editor I had never used before in minutes, after having spend hours achieving an inferior result in Emacs.
The reason for this basically comes down to abstraction levels in a couple of places.
Language support in VSCode is at the 'plugin' level whereas in emacs you usually have to assemble several pieces. Partly this is achievable because VSCode made their own life easy pushing the hard work of language support out using the language protocol. Its widespread adoption in a relatively short time is a great benefit to everyone (emacs included).
That said the only reason I use VSCode instead of Vin is when I program in Typescript because the support is outstanding, always cutting edge, and super easy to set up. Code is ideal for frontend js programming in general with lower investment.
Similar to how awesome Emacs was for Clojure and Lisps in general.
But nothing will peel me away from (neo)Vim for generally everything else. I love how fast, portable, and perfectly customized I’ve made it over the years.
The difference with vim vs emacs vs VSCode is probably like the value with the community size and plug-in support. Just like programming languages become great through having great libraries and frameworks and tutorials etc, being popular has tons of value. After simply being good at all the foundational stuff.
The same is true for emacs, or vim or any other extendable editor. Poor code behaves bad everywhere.
But the real surprise is, VS Code usual performance is equal or better than emacs even with an average setup which is still a tad more powerful than whatever emacs offers on a good setup.
(I don’t mean this as a critique of VSCode. I have never used it.)
I mean, to each their own. Someone else using an editor I dislike doesn’t harm me in any way. But if someone told me that VS Code was “best in class” for anything other than a language I have never touched and have no knowledge of, I’d look at them like they’d just asserted that the sky is green.
To connect this a bit back to emacs, I think the big contribution VSC has made is to popularize the language-server concept, which decouples the UI from the automagical autocomplete and context-sensitive documentation we expect from IDEs.
Emacs's lsp-mode and (I'm told, not yet tried) eglot make it possible to use emacs to productively write java, something I won't attempt without tooling support.
The LSP interface, like slime, enables a whole class of interaction, rather than re-implementing the language support for each languge, like in days of yore.
That truly is a modern coding practice, brought to emacs.
Hardly seen outside first world countries, and even on Europe it isn't easily spot outside the rich EU countries.
I did a couple of consulting gigs where the only iMac available for the Dev teams was used in turns for iOS deployments, for applications done in cross platform frameworks, where 90% of development time was spent in Ubuntu and Windows based computers.
It is possible that "Stack Overflow surveys" select for programmers who tend not to use Emacs. For example, I use Emacs regularly and know what Stack Overflow is, but have never taken one of these surveys.
I'm not even sure how they survey developers. Ask on some crufty mailing list and you probably will get a completely different distribution from the one they showed.
(On a side rant, I really dislike how a lot of websites have normalized “create an account on a website” to mean “Sign up for receiving a plethora of emails about everything the website and its creators are up to these days”)
Hear, hear. If I get an email from a company whose newsletter I didn't sign up for, I immediately unsubscribe... but I really shouldn't have to.
You can do the same thing in Gmail with the +, but some websites filter those out or don't allow them.
Most "normal" people just used other "more visual" editors.
As I learned from the masters I started using more and more both vim for unix tasks and programming and emacs for lisp. Now I use 65%vim, 30% emacs, 5% other editors.
Both of those editors are extremely powerful. But you need to know how to use them. It is not painful for the master to use them, in fact it is automatic and instantaneous and faster than any other editor, a thought becomes an action without conscious intervention, like you thing in playing Do minor in an instrument and your fingers do it automatically, you want to erase a line or replace a word, you think on it, is done.
They are like musical instruments. You could have the best piano or violin in the world, if a mediocre player plays them, you get bad sound.
Most people would be better served with a simple electronic piano or a tablet with lights that point to the next notes of the song, and auto correct them when they play a bad note.
I guess the issue that is being handled here thought is that, just like the piano, the road for those actions to become unconscious is a long painful one.
When I started using Golang for work the first thing that I did was buy GoLand from jetbrains. It just works, and I'm paid for "playing piano", not for "learning how to play piano"
I wish I was able to use emacs professionally but until I'm able to dedicate (usually unpaid) time to learn it, it's just easier to use something else
Also I can move around in emacs and do stuff with macros that has saved me a lot of time. And emacs rarely has problems, unlike visual studio, which crashes occasionally and is permanently sending my dual-core to 100% of both.
Emacs refactoring, heh, not so good... So I use both, do main editing in emacs.
Really? I've always found emacs to be on the slower side of things (not nearly as bad as jetbrains / visual studio, of course) and many keyboard commands to be unnecessarily clunky. I don't know how many times I've given emacs a go, and yet I can't seem to get nearly as proficient as I am with VSCode (and sublimetext before that).
I know part of it is that I don't typically work in languages where having a live REPL up is terribly useful, so emacs support tends to be a bit... second class.
I think my biggest gripe is that there are actually two mountains to climb. First, you have to become proficient with emacs- the chords and so forth. Then you have to find the magical combination of plugins that work together on your operating system with the magical configuration that brings emacs up to par with things that I consider to be table stakes for a good development experience. Doom emacs probably got me the closest there, I think, but struggling to become moderately productive when I already have a tool with which I am extremely productive seems entirely pointless.
Some of the growth that Emacs has enjoyed over the past several years is from folks who want the Vim style modal editing in an editor as customizable and extensible as Emacs. Emacs "distributions" such as Doom and Spacemacs cater to these folks.
Any editor feels clunky for the first week of using it, Vim and Emacs most of all. Nobody wastes the headspace in staying current on multiple editors. So I don't know that you'll ever see an objective comparison of the two. But they're both solid ways to write code, it just takes way too long to get either one dialed in to do the things we expect modern editors to do out of the box, like code completion.
Things were very slow for a few days, and there was a lot of swearing, as I got weird results from hitting a wrong key. But after about a week I was able to get along adequately, and after another one, I was at the point where I was making choices for optimal methods without really thinking about whether typing 2w would be better than holding j for a while.
I think the key was that I made the switch during a vacation, when my workload was lower and I would not be so frustrated by learning enough that I could select between methods.
Learning either vim or emacs in a rush is not good because you are likely to become habitualized on a small subset of methods, and will be blocked from learning other methods that will increase your productivity some day.
Perhaps ironically, mac OS text input boxes are where I use most of the traditional emacs C-/M- keybindings these days.
I use vi-family editors for the same reason I use grep: it’s installed everywhere. I’m not religious about its benefits.
Later on I had to work with a number of different versions of different UNIX platforms on a daily basis (Tru64, Solaris, HP-UX, AIX) as well as multiple varieties of Linux, and vi was a common denominator on all of them.
I've probably worked with 500 developers, if not more.
My personal impression is that Emacs is like the Yeti of programming editors. Everybody has heard about it, few claim to have seen it and even fewer still can claim to have proof of the sighting :-)
I already wrote this to another comment, but quoting myself:
> Is this a USA vs the rest thing? I've worked in many startups in the US and almost everyone uses emacs. Last few years, VSCode has been getting popular though. I had a similar experience when I was a student in UC Berkeley, although it seems like there were more vim users in school than in industry. Anyway, pretty much all my current coworkers use Emacs and I work in Boston, MA.
> Personally: I cannot imagine programming without emacs, to me programming is so strongly associated with emacs...
> Of course, I also understand that it's all personal preference.
I don't know if there is a way to prove that I'm lying. :)
I haven't even used emacs in years so I don't even know anyone that uses it; I stick almost exclusively to Vim (and for 8 months this was my only "IDE"), PyCharm, and WebStorm.
Unless it’s an emacs related conference you will rarely see emacs being used as an editor. You will see a few VIM users sprinkled around. But if it’s a recent conference the vast majority are gonna be VSCode users.
Also, Berkeley as in BSD.
You're probably living in a smaller bubble than mine :-)
- I write software with unit tests. I have a custom method bound to Shift-F5 that computes the test file associated with the current code file, and switches to the buffer.
- I have a similar method bound to F5 that runs the tests for the current file (code file or test file). Ctrl-F5 to run the previous test again even if you're in a different buffer.
- These are configured for multiple programming languages, testrunners, and different conventions within specific programming languages, in different parts of the codebase.
- Test output goes to a first-class buffer, like any other file I'm working on. If I want to do something like `git blame` the file I'm working in, it's also a first-class buffer. Want to run a shell? `tail -f` some logs? All in first-class buffers.
- Why does it matter that things end up in first class buffers? Well, there's lots of random goodies like `meta-x json-pretty-print-region`, so if your execution dumps a blob of unformatted JSON or whatever, you can manipulate it readily. (Tab complete is available on these commands.)
- Autoformat your code automatically with a save hook. Autoformat it on your own schedule by calling something like `m-x blacken-buffer`. I don't think vi does as good a job of manipulating the contents of your file with internal and external programs.
- undo-tree-visualize.
I don't think the things you describe are the differentiators for the Great Editors. For me it's more their phylosophies that make them stand apart: despite the wide usage, vimscript is far more clunky, narrow-scoped and less powerful than elisp. Which means that stitching together something complex is hard and awkward in vim. Emacs is far more suited for complex processing due it's nature of a lisp machine. The chords are awkward though. So, "emacs is a good OS, but it lacks a good text editor".
I would love to see that: everyone I know who uses Vim ends up typing out test names in a separate terminal, or running some sort of a shell-out command that suspends editing of the current file until it is complete, and then hides its output.
It seems like I spend a fair amount of time mosh/tmux to remote servers and I like copying over my Emacs configuration, be up and running. Same for users of vi or vim.
VSCode has good remote server development support also, so there are great options to keep most people happy.
For your anecdata collection.
Most of the other languages you listed have extremely poor Emacs integration, both for cultural reasons (C# devs tended to be on Windows), and because some of those languages are so dominated by other IDEs that nobody bothered to write a good emacs extension. Java is a great example of this; the IntelliJ experience in Java is just so good, nobody managed to come anywhere close in Emacs, which created a self reinforcing cycle.
JDEE (http://jdee.sourceforge.net/) exists, but even I give up on Emacs when I want to write a lot of Java (and I use Emacs for literally everything else, including JS).
The intellisense is amazing too. Start typing a method name and you see arguments with type annotations. it's overkill for scripting, but working on tangled legacy code it's very helpful.
Personally: I cannot imagine programming without emacs, to me programming is so strongly associated with emacs...
Of course, I also understand that it's all personal preference.
And, to be honest, I can't exactly blame them. I tried setting up Calva the other day, just to experiment, and its out-of-the-box experience was far better than emacs'. It was literally just a matter of installing the extension and loading a Clojure project (I was using Leiningen for my project definition, but Calva supports others as well). It brought up a REPL, it started doing autocomplete, and you could even hover over symbols to view their documentation. And none of this required any kind of manual configuration on the part of the user.
At this point, I honestly can't really recommend emacs to any developer who doesn't already know how to use emacs. If you want to start programming, just download VSCode and get the plugins for your favorite language.
Mine isn't either and I find it hard to imagine owning a computer (or using git beyond the very basic operations) without having access to emacs, but it does seem likely that coworkers won't have completely independent text editor preferences. I would expect to see more VS and VSCode in the Redmond, WA area, even at places that aren't Microsoft.
Others claim the opposite. Maybe the contradiction is explained by the hiring culture. Startups with emacs users hire more emacs users. Not that they would make emacs usage an explicit criterion or even ask such interview question. But probably there are some properties over-represented in 4% (or whatever the figure is) of programmers that are emacs users.
Disclaimer: Part-time emacs user since 1986 or so, full-time emacs user since 1989. Should spend some time to learn the newer features / customize it in a more compatible way with the rest of my software. I am lazy to make "another" editor as Stallman puts it even if I like Lisp hacking occasionally, but I would happily switch to a modernized configuration if it were available upstream.
There have always been popular tools. Most of them haven't stuck around though.
Emacs has.
I wouldn't recommend using it right away though. Instead, I'd recommended accumulating some pain by using other popular editor-like,workflow-like,manipulation-like tools, because that might be the only way to appreciate what Emacs brings to the table.
(though I have to acknowledge VSCode's achievement, gaining massive adoption in what has always been a fragmented space)
[0] http://www.cse.chalmers.se/edu/year/2017/course/DAT350/
[1] https://wiki.portal.chalmers.se/agda/pmwiki.php
[2] https://agda.readthedocs.io/en/latest/tools/emacs-mode.html
I've used Emacs for years for editing/programming, running shells and reading news/email.
I've attended two universities in the UK and it was used by default for some of their programming/computational courses; this was in different departments (Physics and CS), a decade apart.
Emacs has been used to build user interfaces (e.g. ProofGeneral, which was the de facto interface for theorem provers like Coq and Isabelle for many years).
Some programming languages de-facto assume they're being written via their Emacs mode (notable Agda; similar to how some JVM languages assume they're being written in Eclipse or IntelliJ).
Years ago I inherited an academic research project which happened to be written entirely in Emacs Lisp.
If one looks at computer history there seem to be several versions of a cycle that looks like “crap underpowered computer slowly gets more features and better performance only to become outnumbered by a smaller slower cheaper computer.” Depending on where one fell in that cycle, emacs may not have been an option (eg if you were starting programming on dos or an early windows you likely wouldn’t be using emacs. If you were starting at the same time using a Unix workstation, emacs might be a reasonable or recommended choice).
During the early naughties you were probably using windows and not exposed to emacs unless you worked on Unix/Linux based web backends.
I'm probably in the minority since, despite a decade-plus of use, I'm by no means a power user. I use a little bit of org-mode and babel here and there. I can hack around in elisp if I want to tweak a mode. But that's about it. To be honest, I don't even compile code or navigate the directory tree from inside emacs.
That being said, two reasons I don't think I'll ever switch. One, the key bindings and commands just feel more elegant. Don't know if that's because they're locked into my muscle memory, or they're genuinely better. Two is that I live in the terminal. IDEs are great, but I much prefer just piping find to grep to sed or similar bash-fu, when I need to do something fancy.
- Former physicist turned programmer