Emacs User Survey (2022)
emacssurvey.org
emacssurvey.org
Would like to see a link for current/past results.
I don't remember any opposition from leadership
Some of the suggested packages would be worthy recipients of donations, but I'd like to throw some cash towards improving Emacs on a more fundamental level. There have been lots of improvements recently but we could certainly do with more.
I know I can donate directly to the FSF, but I don't believe any of that would go towards Emacs development.
If your aim is to make Emacs more accessible for new users, this is not how you're going to get good answers - there will be a lot of bias, as the existing user base probably had very different reasons for why they stayed with Emacs. You might attract a bit more of the same type of user, but the answers won't justify the kind of ambitious decisions that Emacs needs to implement to attract people who otherwise wouldn't consider it.
They should go talk to VSCode users instead, and ask them: did you try Emacs? What made you stay with VSCode instead? Etc. But the truth (as much as I love (hate) Emacs, after almost 20 years with it) might be too much to bear: Emacs' defaults, discoverability, overall polish - just sucks. Even if it is objectively more powerful, the barrier to entry is too high for people who need to focus on getting their work done today.
I don't see how this is a problem. The survey wants to see how existing users use Emacs, not how to make Emacs accessible to new users.
If you want to make a survey to see how to make Emacs more accesible to new users, by all means, create such a survey. But this is not that survey. This survey has a different goal.
I, for one, appreciate the goal of this survey. As an Emacs user myself, I want to get a sense of how other Emacs users use Emacs, which project management packages they use, what completion packages they use, how popular Magit is and other general trends among existing Emacs users. Why is that a problem?
From the survey:
> Which editor did you use before you started using Emacs?
> Can you recall any difficulties you faced when initially learning Emacs?
> How were you introduced to Emacs?
> Which features motivated you to initially try Emacs?
It very clearly looks like the people behind the survey are interested in what aspects of Emacs helped it acquire and retain a user.
Although they say otherwise, it's pretty clear when you observe their behavior that while the devs do care about making it accessible to new users, it is not in their top 5 priorities.
And I'm almost 100% sure that it is not the goal of this survey.
> They should go talk to VSCode users instead
They really shouldn't. Only on HN do I keep seeing comparisons with VSCode. The reality is that a large percentage of Emacs users - perhaps a majority - do not use Emacs as an IDE and making Emacs a better VSCode would not benefit them.
As an example, take a look at the talks in prior Emacs Conferences and note the percentage of talks that have nothing to do with SW development.
Agree that there's plenty to dislike about Emacs' defaults, especially in terms of polish/GUI, but can you elaborate a bit on what you mean by "discoverability"? I find that the self-documenting features are really great: whenever I want to understand what something does or how it works, I can do "describe-function", "describe-key", and "describe-mode", not to mention inspect the actual source-code with just a few clicks. I miss these features whenever I use other programs. If by discoverability you mean "figuring out how to implement a specific thing I'm thinking of" then I'm curious what the ideal solution would be. For me, it's "use a search engine and, failing that, a web forum." But this isn't unique to Emacs: I and most people I know use this approach for all programs, and I don't see how a specific program could improve on it. I'd be interested in alternatives though.
> the barrier to entry is too high for people who need to focus on getting their work done today
This point is often brought up and I 100% agree with it, and think it's important that new users are aware of it. That said, I don't know if there's an easy way to get around it: you get the most out of Emacs once you're somewhat of a power user. To use a simplistic analogy: if you need to travel to the next town and you don't know how to drive, it's probably faster and definitely safer for you to walk or take the bus. Learning how to drive will take time and effort but it will pay off in the long run. My advice to new users is to start slow, use Emacs for only a few small projects, explore different functionalities but don't expect to do everything in Emacs right away, and check out some of the great tutorials out there, like the book "Mastering Emacs" or the "System Crafters" series on YouTube
Sure. Mind you I started on this journey when I was 15 years old, my memory of the initial experience is quite hazy on the details.
The problem is: how do you even discover that things like describe-function or describe-variable exist? The tutorial barely explains how M-x actually works, but also doesn't mention the describe-* functions at any point.
Say you accidentally discover it - type M-x describe-function, press <tab>, and are now presented with a daunting list of potential things to learn about. None of the names make sense out of their context, most will be irrelevant for the problem you're trying to solve. Even if you're not solving a problem, but just exploring - how do you find out what's interesting to look at? You look up a couple random functions, figure you don't know why they would be useful - do you even come back to use this system again?
The Emacs nomenclature is often different from what you're used to from literally every other system (paste is yank, window is frame, cursor is point, close OR cut is kill, etc). When you're looking to solve a specific problem (what is the name of the function that I want to bind to Ctrl-v, so I can use it to paste text?), it's very difficult to deduce that the keyword to look for is "yank". How do you even find out you can customize something, if you can't name it?
Meanwhile most of the things that keep me hooked to Emacs nowadays, are hidden gems (both tiny and big) that you'd never learn about, unless someone else hinted you in that direction: magit, tramp, server, align-regexp, fill-paragraph, sort-lines, describe-* - in some cases, it literally took me _years_ to find some of these exist.
The main reason I stuck with Emacs, was that a lot of people kept hyping it as powerful and customizable. But none of the power and customization was easy enough to unlock - not even for a 15 year old, with an overabundance of free time, enthusiasm, and curiosity. The older I get, the simpler my config - I no longer have the time or will to keep tweaking or fixing things. I'd probably switch to VSCode if it had anything half as good as magit.
> To use a simplistic analogy: if you need to travel to the next town and you don't know how to drive, it's probably faster and definitely safer for you to walk or take the bus. Learning how to drive will take time and effort but it will pay off in the long run.
Excellent analogy, and it just happens that I have an excellent counter-argument! I moved to Vienna, a city with public transport system that is so cheap, reliable, and well-connected, that many people don't even care to get a car. The building I live in has 40 apartments, and an underground garage with... 6 cars in it? But when you do need a car, the road system is still there and is pretty efficient.
I would click on "Help" and it gives a lot of help, including Describe>Describe Key or Mouse Operation.
I learned Emacs slowly and piece by piece. But the quality of "third-party" tutorials I've been seeing (like Mastering Emacs and System Crafters, or DistroTube) is quite high. And the forums (reddit or emacs.stackexchange) are quite welcoming.
> it's very difficult to deduce that the keyword to look for is "yank". How do you even find out you can customize something, if you can't name it?
The nomenclature is kind of annoying, though there's good arguments for keeping it that way (mostly around legacy reasons, but also because the names have specific Emacs meanings, eg "point" is not exactly the same as "cursor", "kill/yank" is not exactly the same as "copy/paste" etc). But getting used to these things and figuring out how to use them is really just a web-search away in my experience. You just type "how to copy/paste in Emacs" and you'll come across tons of useful information. Obviously this isn't thanks to Emacs itself, it's thanks to the internet, but my point is that it seems a reasonable assumption that modern users will mostly use this approach to get acquainted with a new system.
In my experience, relying on a search engine/web forums/other expert users is the typical way to learn new software tools. Isn't this how people learn how to use git, or the Unix-style command-line? Commands like "rm", "mkdir" or "rebase" are unfamiliar and even confusing until you take the time to figure them out.
I've done the same when using different IDEs: I don't even know if Eclipse has an official manual/tutorial. But Emacs still beats most other IDEs in terms of discoverability because, after figuring out that "paste" is done by "yank", I can easily look at the internal documentation for the function (which is, granted, quite verbose, but detailed and exhaustive) and even its source code.
> a city with public transport system that is so cheap, reliable, and well-connected, that many people don't even care to get a car.
I agree with your point here; I wouldn't call it a counterargument as much as an extension of the analogy. Public transport works perfectly for people traveling around the same routes. Most IDEs offer less customization but are optimized for specific (common) uses. But if you're going to want or need to use your IDE and system in specialized way, or if you just like to tinker and customize a cool program, you'd benefit from learning how to use Emacs.
It actually does, but not by name. It points you to the help system. In particular:
- C-h a - help apropos, search for commands by part of the name getting a list
- C-h k - describe-key
- C-h c - describe-key-briefly
- C-h f - describe-function
- C-h v - describe-variable
All of those are in the tutorial.
Personally one of the best features in emacs for me is the ease you can make both simple and quite complex macros in order to get quantitative work done fast. Here is a list of 200 or 2000 lines of some data that need to be turned into commands or other data, and it might be over several lines or where some data need to be referenced from some other file or files. It is an great companion to the shell in those work situations, and I have yet to find a better tool when I don't want to spend the time to write a proper shell or python script.
Quite so even for a regular user, as many of us use or care about only a fraction of the available features. The demand "must be answered", didn't appeal to me.
It took me a while, but I’ve finally adjusted to Sublime and am quite satisfied for now. It’s snappy and doesn’t break as easily. The only issue I have is that, unlike Vim and Emacs, Sublime macros seem to record movement by characters, not text objects. So if I move cursor by words inside a macro and then replay it in another place, where words have different lengths, the macro won’t do what it should. For those cases I’ll still switch to Vim probably.
[1]: On Windows my config doesn’t work at all. I have no idea why. I didn’t have the energy to debug it.
The Emacs devs definitely are biased in favor of free platforms, that’s true. However something like 30% of users are on MacOS and I’ve personally never noted any deficiency there. The native Windows builds definitely don’t run as well though. A big part of that is because NTFS is poorly suited to Emacs IO patterns.
I use the same config for all three, but I did have to disable certain parts when running on Windows. One that immediately comes to mind is the vterm package.
This strikes me as shortsighted. Most of us don't have much control over the platform we use.
I, for example, was a very happy (even mildly evangelistic) emacs user up until my last job change. The new company issued me a Windows laptop. After a couple days of fussing with trying to get it to work acceptably well on either native Windows or WSL, I finally gave up and switched to vscode.
This probably spells the doom of my use of emacs for hobby work, too. Virtually all of my programming time happens at work these days, so my emacs proficiency is rapidly declining. Soon not even nostalgia will be able to overcome the inconvenience of using an editor that's becoming decreasingly familiar by the day.
I suppose I am only one person and I don't speak for everyone, but being able to spare at least a little more love for Windows users might have prevented at least this one developer from attriting out of the community.
More likely it simply reflects the platform they use.
Well, that's the thing.
This is NOT my POV, but I have definitely heard true-believer libre/Free software people opine that making it too easy to use Free software on nonFree platforms isn't desirable.
I think this is a silly perspective, but it's definitely one that's out there.
I don't use much libre software in my day to day (desktop) life because most of it is only good enough if you feel strongly that libre is a value unto itself, and worth hassle. I mostly don't. I mean, in some places, there's definite parity or even advantages on the libre side, but holy crap on the desktop it's bleak.
https://www.gnu.org/software/emacs/download.html#nonfree
Whether this is a realistic, good, or successful point of view, will clearly be debated endlessly, but Emacs' intentions should be understood clearly.
IMO, there is a gray area between "such a bad experience that many Windows users will not see its value" and "so good that it's just another piece of good Windows software". Finding a practical balance, if it's even possible, would be another area for debate. There are surely mailing list archives that cover this, but I think the project would always strictly prioritize "avoid enriching the Windows experience" over "show Windows users how good Emacs is."
I imagine emacs 28 wouldn’t run well on those specs with a default confit.
But also the biggest killer is probably the lack of code trees, forward/backward searches to do syntax highlighting etc is pretty expensive.
What specific issues do you face? I've been using Emacs both on Mac and Linux for >= 10 years and never really had any problem. Genuinely want to know what problems other Emacs users on Mac face?
In general, emacs locks up on me in OS X but not so in linux. I don’t have more info than that, but I find I have to restart emacs more than pycharm
I'm a Linux person, but need Windows for work. I've used Emacs on Windows for over a decade now, and with the exception of magit, everything works just as fine as on my Linux machine. In fact, I have the same config for both, with only a few lines dealing with Linux vs Windows specifics.
So it may be worth debugging your config.
I use emax64, BTW: https://github.com/m-parashar/emax64
check out: https://emacsformacosx.com/
That said, occasionally upgrading doesn't work as expected, and I stay with the previous version. I'm on 27.2 because something didn't work on 28.x and I haven't debugged it.
Hydra (most could be done in transient or without a menu), project.el (built-in), magit, org-mode, org-ql, ivy/counsel, company, lispy, smartparens-mode.
I should probably declare configuration bankruptcy and try starting over from scratch.
Last time I did was in 2016 and while it was a pain it did result in a much nicer structure for my init file and lisp directory.
Give Doom a try. Even if you're not a Vim (Evil) user. What I like about Doom, is that it has nice package management and an easy-to-navigate structure of modules. Also, it has a relatively small core and doesn't get in the way of you changing things around. It includes CLI tool you can use to update packages and verify the validity of your config. And because of macros like map!, after!, add-hook!, defadvice!, undefadvice!, add-transient-hook!, cmd!, etc. it seriously cuts down a lot of boiler-plate in the config.
I don't even use most of the "official" modules included, I use them as some kind of recipes to borrow ideas from. If for any reason in the future, I decide to leave Doom and build my config from scratch, I probably still end up using a bunch of things from its core.
In any case, what did you answer regarding the 'favorite packages'? For me more or less in order of appreciation:
magit, org-mode (it is growing on me more and more), multiple-cursors, projectile, ido (although currently trying ivy), bubble-buffer, use-package, ag (should switch to rg I guess), company+lsp-mode (need to try eglot)
That was reported a few times in other places. According to the maintainer, there's a bug with the display/exporting, but the whole data still gets correctly recorded.
c.f. https://lists.gnu.org/archive/html/emacs-devel/2022-10/msg01...
org, magit, evil, tramp, ispell
I could live without ispell or tramp, but if any of the first 3 go away I'd switch to Vim or maybe VS Code.
- ws-butler: fix whitespace only on the lines you've changed. Great for collaborating as well
- eglot
Emacs-lisp is probably the single biggest Lisp in 2022, certainly by number of users, and most likely also by total SLOC in the wild.
I am the psychotherapist. Please, describe your problems. Each time
you are finished talking, type RET twice.
Emacs? Hah! I would appreciate it if you would continue. * Emacs Usage
- Which of the following activities do you use Emacs for? :: missing
- How many years have you been using Emacs for? :: missing
- Which version(s) of Emacs do you use? :: missing
- Which features keep you using Emacs? :: missing
- Which operating system to you use Emacs on? :: missing
"I have investigated a number of cases like this, and in every one the data has been correctly recorded in the database, but for some reason it is displayed/exported incorrectly."
https://lists.gnu.org/archive/html/emacs-devel/2022-10/msg01...
Guess they're just not interested in my opinion.
Fair enough, I'm not the target market for this survey.
Nice joke.