[HN Gopher] Emacs User Survey - 2022 Results
___________________________________________________________________
Emacs User Survey - 2022 Results
Author : gmemstr
Score : 86 points
Date : 2022-12-18 11:04 UTC (11 hours ago)
(HTM) web link (emacssurvey.org)
(TXT) w3m dump (emacssurvey.org)
| ykonstant wrote:
| He he; all I see is a very cute bad gateway pic.
| forgotpwd16 wrote:
| Alt:
| https://web.archive.org/web/20221218110505/https://emacssurv...
| forgotpwd16 wrote:
| Those are raw results, not edited for presentation. For example
| "favourite packages" just gives answers as is rather considering
| that input was comma-separated list. Interestingly a significant
| majority of surveyees are from HN and r/emacs. And for anyone
| seeing the "Vector{String}" and wonders, yes, the framework
| utilized for the survey is written in Julia.
| usr1106 wrote:
| Unusable at least on my phone. When I extend "What are the
| biggest strengths" I seem to seen thousands of free-text
| answers. Scrolling never ends...
| celeritascelery wrote:
| The author of the survey gave a presentation at EmacsConf that
| does a little more analysis of the results.
|
| https://emacsconf.org/2022/talks/survey/
| pxc wrote:
| Heads up for those who try the video and ditch it due to
| crappy audio: the audio-only Opus recording sounds fine
| NeutralForest wrote:
| Good steps are taken for Emacs 29: use-package, eglot, tree-
| sitter are coming to core!
| kstrauser wrote:
| That's three less things I have to install afterward. It also
| means that each of those can be used in the official docs as
| the standard way of doing their respective things, which is
| great news.
| tgv wrote:
| The fact that about 10% maintains an elisp package, and that
| about 90% can program in elisp, makes me suspect the outcomes are
| skewed. Either that, or emacs is doomed.
| natrys wrote:
| Or it's not so much the outcome that is skewed, but Emacs
| attracts a certain type of people in the first place. This is
| not a doom, rather a boon.
| grumpyprole wrote:
| Elisp is really easy though, far easier than trying to write a
| VSCode plug-in.
| gpderetta wrote:
| it is a bit like shell scripting; you start with useful
| oneliner in your .emcas and with time and patience they might
| grow into fully fledged "plug-ins".
| TacticalCoder wrote:
| > Either that, or emacs is doomed.
|
| 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.
| agumonkey wrote:
| doomed ? because of rot ? i'm not involved in emacs-devel but
| I've never seen so much activity in emacs core and core
| packages. it seems emacs survived very well before having that
| much contribution, which makes me believe it's gonna be fine.
| blahgeek wrote:
| > or emacs is doomed.
|
| Can you elaborate? Isn't a high developer/user ratio a good
| thing?
| NeutralForest wrote:
| No, it means that only people highly involved in the
| ecosystem keep using Emacs. Ideally, you'd like people
| completely unaware of how it works to use it; like for VSCode
| for example.
| pluijzer wrote:
| The low maintainer/user ratio could be explain by the low
| barrier that Emacs provide to extend it in comparison to
| other editors like vscode.
|
| 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.
| tgv wrote:
| Emacs definitely doesn't have a low barrier. How many
| people know LISP in the first place?
|
| > 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.
| 3836293648 wrote:
| You learn lisp because of emacs, not the other way around
| gpderetta wrote:
| I don't think that emacs need to cater to those with very
| shallow understanding [1] to survive. It has prospered
| for decades in its niche and I think it is perfectly fine
| like this. The percentage of developers that use it might
| shrink, but the absolute numbers are very likely going
| up.
|
| [1] mind, I don't think that emacs requires very deep
| understanding either, but I might be overestimating the
| average programmer.
| User23 wrote:
| > How many people know LISP in the first place?
|
| 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.
| donio wrote:
| Yep, people tend to ignore the time spent mucking about
| with GUI based configurations even though it often adds
| up to enormous amounts of time. The big difference
| between the two approaches is that the effort I've spent
| customizing Emacs has continued to pay dividends over the
| past 20 years. And I only had to make each change once
| instead of every time I move to a new computer.
| kace91 wrote:
| Alternatively, you are confusing familiar with intuitive.
|
| 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".
| User23 wrote:
| > Alternatively, you are confusing familiar with
| intuitive.
|
| 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.
| aeonik wrote:
| This is definitely partially true, I'm already working on
| my own package after only having used emacs for a few
| months.
|
| 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.
| wara23arish wrote:
| in case u didnt know
|
| 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
| tmtvl wrote:
| _M-S-x_ , actually, _C-M-x_ is _eval-defun_ in Elisp mode
| (and similar functions for Slime and Geiser).
| NeutralForest wrote:
| Fair enough, I just don't have sufficient numbers and
| analysis to have a good opinion on this.
| gpderetta wrote:
| Things is, with time you will learn a bit of elisp by
| osmosis, if anything else by copy-pasting bits from the
| 'net and then playing around with it. So it is not very
| surprising that many emacs users know a bit of elisp.
|
| 10% being plugin authors is a bit surprising to me and it
| is possible that the survey is somehow skewed.
| ergonaught wrote:
| It seems likely that only people highly involved in the
| ecosystem completed the survey, because only people highly
| involved in the ecosystem would even know that the survey
| existed.
| e3bc54b2 wrote:
| > about 10% maintains an elisp package
|
| 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 :)
| NeutralForest wrote:
| Good points, but rn it seems that Emacs is playing a game of
| catching up. Thinks like LSP integration, tree-sitter are
| coming now but it's still really rough. I'm glad they are!
| But we're not there yet.
| pritambaral wrote:
| Merging into core is not really needed for a feature; it
| just bakes it in. That's the point of emacs: it's made to
| be extended, no need to draw a line between a user and a
| developer.
|
| 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.
| NeutralForest wrote:
| I just don't agree, a text editor/IDE should have user
| ergonomics in mind. The fewer steps there are between
| your spinning the IDE and having a working setup, the
| better it is for the end user.
|
| 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.
| yaantc wrote:
| It's a reasonable position for most text editors / IDE,
| but not a good fit for Emacs IMHO. Emacs is atypical
| here.
|
| 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!
| tazjin wrote:
| > The fewer steps there are between your spinning the IDE
| and having a working setup
|
| 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.
| adalacelove wrote:
| I think there will always be some kind of tension. This
| forces everyone to agree on a particular choice, which
| may annoy some people but makes it easier to build on top
| of it. I think that as a matter of fact emacs is highly
| opinionated, starting with its very extension language,
| elisp.
| NeutralForest wrote:
| I just disagree with this view, lots of people use it to
| code. It should be easy to setup a coding environment
| with it. That's all I mean.
| celeritascelery wrote:
| The Emacs frameworks (doom, spacemacs, etc) make it
| pretty easy to setup. That being said, if your primary
| concern is ease, vscode would be a better choice. Emacs
| is more focused on power and extensibility.
| NeutralForest wrote:
| I know, I'm using Emacs everyday. And I dislike the
| frameworks because they obfuscate what's going on in
| Emacs, at least to me. I just think that since we're
| pushing features like eglot or tree-sitter to core, we
| should also focus on making them easy to use.
| _a_a_a_ wrote:
| Long term emacs user, and I agree. I need to learn to
| program it but more importantly, I should be able to
| install a package and have it work because I use emacs
| for just that - work.
|
| There's too much 'add this include your .emacs' etc. But
| it's getting better.
| Forge36 wrote:
| It's a text editor first. I'm not using it for code. I'm
| using it for magit and org-mode
| 323 wrote:
| For those who don't really know what Emacs is (besides being an
| editor), I found this overview video from Steve Yegge as
| excellent. I never used Emacs, so it was very informing for me:
|
| 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.
| xenodium wrote:
| If anyone's looking for short demos, the https://emacsrocks.com
| shorts are great. My all-time favorite is
| https://emacsrocks.com/e13.html (well worth watching until the
| end).
|
| edit: I also post the odd demo at https://xenodium.com
| 323 wrote:
| You can do some of the multi-cursor stuff in VS Code.
|
| Missing are editing the directory listing to rename files,
| doing calculations inline on text and making the whole thing
| a macro.
| lifeisstillgood wrote:
| Steve Yegge has a Youtube channel !!??
|
| I just subscribed
| kkfx wrote:
| Try https://youtu.be/B6jfrrwR10k instead :-)
| hollerith wrote:
| >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.
|
| 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.
| tweetle_beetle wrote:
| I'm sure there are many interesting reasons to prefer Emacs
| to VS Code, but lack of offline documentation surely isn't
| one. Installing an Emacs package is not significantly easier
| or less technical than downloading a git repository.
|
| - https://github.com/microsoft/vscode-docs
|
| - https://vscode.dev/github/microsoft/vscode-
| docs/blob/main/ap...
| hollerith wrote:
| I cloned github.com/microsoft/vscode-docs during my
| explorations of vscode. It proved much harder for me to
| work with than the documentation for Emacs is. I downloaded
| some NPM package (pardon me if I don't look up which one)
| to serve the markdown files in the repo on a port on my
| local machine, which worked okay I guess, but I never found
| a way to search the markdown files that is more graceful
| than using grep on the markdown files, which gets me the
| names of the files of interest, then using the
| aforementioned NPM package to visit the file, then using
| the find command in my browser to search for the lines of
| interest that grep printed.
|
| 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).
| 323 wrote:
| > _but I never found a way to search the markdown files
| that is more graceful than using grep on the markdown
| files, which gets me the names of the files of interest,
| then using the aforementioned NPM package to visit the
| file_
|
| 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.
| hollerith wrote:
| I tried that, but did not stick with it. I am almost
| certain the reason I didn't stick with it is that I hated
| the internal markdown viewer. This was about 4 years ago.
|
| Thanks for your suggestion.
| hprotagonist wrote:
| M-x package-install RET <name of package> RET
|
| at its simplest, anyway.
| srcreigh wrote:
| Does VSCode link you to the file a built in command is
| written in? In emacs not only can I read built in command
| source code. I can even change it and reload the functions
| on the fly.
|
| 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.
| Archelaos wrote:
| I wonder what conclusion people want to draw from such a
| "survey". Whom does it represent? Only people who happen to know
| about the survey and felt motivated enough to work through it. I
| would therefore guess that it was highly networked Emacs power
| users and avid consumers of tech news who participated. -- It's
| hard to escape the echo chamber.
| pjmlp wrote:
| That is why statistics then has stuff like distributions,
| confidence intervals and such.
| celeritascelery wrote:
| How do you think the results would be different if "all" Emacs
| users were polled? I would expect significantly less packages
| used and less elisp proficiency.
| [deleted]
| morelisp wrote:
| I'm not sure about "less packages used." Anecdotally it's the
| new users who install a massive amount of "plugins" from
| ELPAs and the more experienced ones slowly integrating a few
| large packages but mostly custom code into their workflows
| over 20+ years.
| Forge36 wrote:
| I'm brand new (only started in past 9 months). I took the
| survey.
|
| That's a great question to include next time
| grumpyprole wrote:
| I've been using Emacs for over 25 years, sadly I missed this
| survey.
| [deleted]
| yaantc wrote:
| I agree but still find the survey interesting. It shows what's
| actually used among (power) users, which can sometimes give a
| different perspective from web/email discussions that naturally
| are biased toward new things.
| philonoist wrote:
| Offtopic: Why did Spacemacs development stop? They didn't have a
| stable release from 2018.
| opan wrote:
| Unsure if anything changed, but even the first time I ever used
| Spacemacs, they recommended the development branch. Some
| projects are allergic to cutting releases for some reason
| (pfetch hasn't had one in years).
|
| edit: Here is a relevant issue with some discussion
|
| https://github.com/syl20bnr/spacemacs/issues/11191
| [deleted]
| [deleted]
___________________________________________________________________
(page generated 2022-12-18 23:03 UTC)