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.
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.