Emacs User Survey – 2022 Results
emacssurvey.org
emacssurvey.org
https://www.youtube.com/watch?v=lkIicfzPBys
One particular aspect that intrigued me: you can extend VS Code (and similiar), but it's a lot of work and boilerplate to create a plugin whose actual functionality is 3 lines of code (let's say toLowercase()). In emacs, you can just write those 3 lines of code and that's it, that's your plugin.
edit: I also post the odd demo at https://xenodium.com
Missing are editing the directory listing to rename files, doing calculations inline on text and making the whole thing a macro.
I just subscribed
This right here is the main reason I'm still using Emacs.
Another thing that makes it easy to extend Emacs is that the (freely downloadable) documentation on how to extend Emacs is very well written and organized -- much more so than the documentation on how to extend vscode for example.
And it is easy to obtain a local, offline copy of all the documentation I need to extend Emacs by installing a couple of packages in my package manager of choice (namely, one package containing Emacs's source code and one package consisting of the Emacs Lisp Reference Manual).
For a few years recently I didn't have a net connection in my apartment. (I still had access to the net by walking to a community room in my apartment building.) During those years, I spent hundreds of hours in my apartment modifying Emacs -- often quite complicated modifications -- but only a few times did I feel the need during one of those Emacs-modification sessions to leave my apartment to look something up on the net.
In contrast, while extending vscode, a coder needs to be connected to the net because all the documentation is on the net, with no easy or even medium-difficulty way of obtaining an offline copy that I have been able to find.
- https://github.com/microsoft/vscode-docs
- https://vscode.dev/github/microsoft/vscode-docs/blob/main/ap...
Also, there is a ton of basic information about web development that I needed to learn to try to start modifying my vscode install which of course is not included in that repo (vscode-docs) and I never found an easy way of getting an offline copy of that information. In fact, IIRC I didn't even find troves of markdown files that could be cloned with git or other shell one-liners.
Also, I have actually spent 100s of hours modifying Emacs "in anger" (i.e., although I wasn't getting paid for the work; the work was done as an earnest attempt to make my computing experience better or to make me more productive) while offline. Are you saying you've done the same with vscode? Heck: have you done that with any software implemented on web tech?
I hope I don't sound combative: I really want to know if such a thing would become possible for me if I invested more of my time in learning web tech.
I ask anyone reading this (not just the person I am replying to): is there anyone out there who routinely works on software implemented on web tech (i.e., browser or Electron or such) while disconnected from the net?
For a definition of "disconnected", let us use this: it would take at least a few minutes of work (e.g., I must walk out of my apartment to another part of my apartment building to use the net) or at least a few minutes of waiting (e.g., I have internet service in my apartment, but I usually keep the modem unplugged, and every time I plug it back in, it takes a few minutes for the connection to come up and become usable).
You can use VS Code itself for this, open in it the directory with the markdown files, use the VS Code internal search to find the file you need, and look at it in the internal VS Code markdown viewer.
Thanks for your suggestion.
M-x package-install RET <name of package> RET
Sometimes I find config options by reading source code easier than documentation. C-h f <func>, click elisp link, C-s defcustom.
I recently used this to fix horizontal rules for the doc polyps for rust language server. Turns out eglot uses eldoc which uses markdown-mode, and markdown-mode has an option for the character used to draw horizontal rule.. Tamsyn font doesn’t render Unicode em dash properly so I replace it with normal dash.
Can you elaborate? Isn’t a high developer/user ratio a good thing?
Most people I have met using vscode use it very vanilla, maybe thet use a handful of plugins bit non of them have written custom code for it. All Emacs users I have met though were quite fanatical in customizing the editor.
That being said, as a a newbie, even when M-x <command> it's pretty hard for me to figure out commands.
Documentation is also a bit hard for me to understand and seems to assume you know what you are doing already.
I think having the menu system expose more commands from minor and major modes might go a long way to reducing friction from new users.
C-h m
i believe that lists all of the functions/variables of the current major mode you have
I think also C - M x (not sure abt this one) is like M-x but basically only displays commands related to the modes you have active
> All Emacs users I have met though were quite fanatical in customizing the editor.
Indeed, and that's the bias of the poll, too. So emacs has a problem getting people on-board. I got into emacs via a Symbolics. It was great, back then, but it's such a specific combination of skills, and the user experience of emacs is completely outdone by e.g. VSCode. Add to that that most devs nowadays have a very shallow technical understanding, and emacs seems to be cornered in a niche. The only opportunity I see for it to come back is when the terminal interface becomes fashionable again.
[1] mind, I don't think that emacs requires very deep understanding either, but I might be overestimating the average programmer.
The basics of Lisp are trivial. I’d happily no-hire any supposed developer that couldn’t easily pick it up.
> and the user experience of emacs is completely outdone by e.g. VSCode.
I heard this too. I was starting a new job using Ruby, which I hadn’t used in years. Despite being a long time Emacs user, since I hadn’t used Emacs in a few years and by far the most popular editor used by my team was VS Code, I thought I’d give it a shot. To my surprise it didn’t work anywhere near out of the box. I, and other developers on slack too, spent several days mucking with plugins and configs to get sorbet and other language servers working. At that point it was still a laggy lousy experience, but one where I was forced to use the mouse and had poor discoverability. So I said eff this, pulled spacemacs, and had a fully featured lsp based ruby IDE customized to my liking in about four hours.
My conclusion from all this is that people say VS Code has a superior user experience they either don’t know what they’re talking about or are drawing the most superficial of conclusions.
If you hit a wall with vs code, which many people consider the most user friendly editor because of lack or familiarity, imagine how it is for emacs newcomers, when the community’s approach to user experience is “you’re a user? Nope, you’re one of the devs now”.
That's why I mentioned that other developers were having the same problem. There were dozens, if not hundreds all struggling to get a decent Ruby IDE going in VS Code. Enough so that documenting and sharing VS Code config became a week long hack days project. My familiarity with Emacs doesn't explain that away.
> If you hit a wall with vs code, which many people consider the most user friendly editor because of lack or familiarity, imagine how it is for emacs newcomers, when the community’s approach to user experience is “you’re a user? Nope, you’re one of the devs now”.
I never claimed that Emacs doesn't have a learning curve too. My claim is that VS Code required at least as much effort to configure to be a proper Ruby IDE as Emacs did. And that's not an argument, it's a factual statement based on my experience and my observation of my peers' experiences. Maybe VS Code is a great out of the box IDE for some blub, but as soon as you need to configure it, it's just as much of a hassle if not more so due to its inferior discoverability.
You do raise a good point though that the Emacs community has a high average level of respect for Emacs users. It's one of the things I find refreshing. Even in places like reddit where the default discourse is around the cesspool level, the Emacs community is great and practically encourages achieving competency and then mastery.
10% being plugin authors is a bit surprising to me and it is possible that the survey is somehow skewed.
IMO that is probably better than most other ecosystems where this percentage is often 1-3%.
> about 90% can program in elisp
Emacs doesn't really make a distinction between user and developer, and its a major driving principle behind the whole endeavor.
> makes me suspect the outcomes are skewed
Very much possible. But the survey was advertised over HN, matrix, IRC and Reddit. The last being a lot more 'general' audience than other 3, which I expect skews other ways. Anyway, knowing what Emacs is itself is a selection bias, so this is hardly unexpected.
> or emacs is doomed
If current breakneck speed of development of core Emacs as well as ecosystem at large is any indicator, I'm not preparing the doomsday shelter any time soon :)
LSP integration has been available for very long time, just not from the core emacs repo. For example, Ubuntu does not ship with Blender, because no official build of Ubuntu is available with Blender pre-installed in the iso, but that doesn't mean Blender is not available on Ubuntu. Emacs is a lot like that.
Similarly for tree-sitter. Available as a package for a while, only now also available built-in. An Emacs release is not needed to get a feature in Emacs.
Extensibility is important and useful but it also comes at a heavier mental load for users because it introduces complexity, and Emacs is already complex enough imo.
What you're overseeing here is that Emacs configurations are usually highly individual, and that "a working setup" for _you_ does not mean the same as it does for _me_.
For example, regarding LSPs, I only use them in very rare cases because usually LSP implementations themselves (regardless of the editor you use them in) are buggy and/or slow.
For me it's much more important that the actual _text editing_ experience is consistent across languages, than the tooling for any particular language.
There's too much 'add this include your .emacs' etc. But it's getting better.
I agree. It wasn't obvious to me, at first, that Emacs is not a code editor, rather just a Lisp program for editing lots of text. And I didn't even know what Lisp was at the time, so it wouldn't have helped either way. But ...
> It should be easy to setup a coding environment with it.
It kinda is. I started using Emacs with just a Spacemacs install. And I didn't need to learn anything about Emacs for a long time after that. It was only when Spacemacs stopped being maintained, and I started facing issues due to that, that I looked deeper. It helped that I had learned what Lisp is (Common Lisp, though, not Emacs Lisp) for it to finally click, so I got lucky that way.
Now, even when I know Emacs (and Emacs Lisp) rather well, I still stick to Doom Emacs to "setup a coding environment with it".
Emacs is best understood as an editor construction kit with a default editor as an example. It's a "build your own editor" Lisp environment. And it's really more "text based applications" rather than just editor. Add some support for images and SVG on top too, although it's not as central as text.
Nobody fully build its own Emacs variant of course, there's a lot in the core Emacs (with a surprising amount of features disabled/hidden by default!) and it's most of anyone Emacs variant. Still, the approach of putting up one's "own" Emacs is important. I'm using over 50 packages, with a ~100 kB init file and Emacs distros are way above this I guess. The basic experience is if I want something to work some way, I'll look for supporting package(s) and tune them as I want, or much more rarely write some Elisp.
Making Emacs more approachable to newcomers is a recurring discussion in the Emacs world. For historical reasons there's a barrier, as Emacs predates a lot of things (GUI windows so in Emacs a "window" is what's a text pane in other editors, Ctrl-X/C/V so it's C-w/M-w/C-y in Emacs, etc.). Changing this would be disruptive to current users, and Emacs puts a lot of weight on being backward compatible. It's not possible to please everyone here.
In the end, I don't think Emacs "alieness" is a problem. The differences are rather superficial and easy to learn (with some motivation). For people not interested in this, there are plenty of alternate editors that focus on being user friendly, and it's perfectly fine. Choice is good.
Much more important to the Emacs experience is the ease of customization and adaptation. The Lisp environment is a big part of this: once you know the basics the embedded documentation is very extensive and always accessible. It's trivial to get the documentation on any function or variable, and go to its source code. It's also straightforward to adjust any behavior. There is no difference between core elisp code and the user code. Changes to the core are done in a conservative way to avoid breaking all the current users customization (there are breaking changes, but with early obsolescence warnings and good change documentation). All this is a much more important part of Emacs than the early experience. It's also quite specific to Emacs, I'm not sure there are many alternatives? If any, they're also "not so user friendly" (like neovim with Lua now?).
In summary, there's a tradeoff being first user experience, backward compatibility with such a long history, and flexibility to accommodate very different needs and use-cases (some of them incompatible). Emacs has a specific situation here. It may not be to everyone taste, but it's OK: there are plenty other alternatives. There's a thriving community, improvements have never been as speedy. I'm a happy user seeing no reason to change, on the contrary: I really feel it's getting better and better!
I think that the kind of people participating in the survey do skew the results but in any case... Emacs is thriving atm.
I've never seen so much interest in Emacs as lately. I've been using it since the late nineties, with a short XEmacs stint, and still use Emacs to this day. And it keeps only getting better and better.
I don't see Emacs as being doomed at all.
That's a great question to include next time
edit: Here is a relevant issue with some discussion
https://github.com/syl20bnr/spacemacs/blob/master/core/info/...