Emacs User Survey (2022)(emacssurvey.org)
emacssurvey.org
Emacs User Survey (2022)
https://emacssurvey.org/
101 comments
I would very much like to donate some cash to improving Emacs in general. It's been by far the single most powerful tool I've ever learnt and it's been a huge productivity boost.
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.
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.
The power of HN! There were 9 sponsors on github for Daniel Mendler, when I finished filling my sponsorship info, the number increased to 12. This survey really helps.
Exactly the same experience for me. So now my survey responses about financial support are no longer correct.
Haha, I thought I was the only one guilt tripped at the end questions about financially supporting emacs,
Here are the 2020 results:
https://emacs-survey.netlify.app/2020/
https://emacs-survey.netlify.app/2020/
I'm not sure if this survey even has the support of the Emacs authors. There was a big controversy about collecting this data on their mailing lists about a year ago so I'd be careful about donating money to the anonymous person who's collecting data on Emacs users without the support of Emacs.
The survey links to donation pages for the FSF, org-mode, high-profile package authors, and separately the creator of the survey. They're not some sort of middle man for the payment.
Here's the discussion for this year: https://lists.gnu.org/archive/html/emacs-devel/2022-05/msg00...
I don't remember any opposition from leadership
I don't remember any opposition from leadership
I will give just some in the next months. They really deserve it.
One problem with this survey is that while it is primarily aimed at existing users, it asks questions about learning curve, defaults, first time experience, what editor did you use previously, etc.
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.
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.
> Emacs' defaults, discoverability, overall polish - just sucks
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
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
> [...] can you elaborate a bit on what you mean by "discoverability"?
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.
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.
The problem is: how do you even discover that things like describe-function or describe-variable exist?
I would click on "Help" and it gives a lot of help, including Describe>Describe Key or Mouse Operation.
I would click on "Help" and it gives a lot of help, including Describe>Describe Key or Mouse Operation.
I just looked at the help menu, and with the amount of options presented... I think it serves to prove my point.
> The tutorial barely explains how M-x actually works, but also doesn't mention the describe-* functions at any point.
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.
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.
I see.I think we're in partial agreement regarding "discoverability" then, although I wouldn't call it "discoverability": I'd say the problem is more simply due to the fact that the tutorial is out-of-date and not very user-friendly. When I started using Emacs I barely looked at the tutorial: its first focus is on how to navigate paragraphs of text using Emacs key-bindings, but as soon as I realized the "normal" bindings (using arrows) worked, I ditched the manual and opened the file I had to work on.
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.
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.
> One problem with this survey is that while it is primarily aimed at existing users
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?
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?
> The survey wants to see how existing users use Emacs, not how to make Emacs accessible to new users.
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.
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.
The survey is in part very focused on programmers and developers, which is the context which I will read the results when those are being presented.
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.
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
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.
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.
Check my other reply: https://news.ycombinator.com/item?id=33332991
forums telling you emacs works just fine on Windows but then realizing then extesions creators didn't get the memo because they're passing unix paths to external binaries and windows binaries don't like that.
Yeah, it's ridiculous how many packages break on Windows.
Something neat about this survey: one of the org-mode maintainers put this together. One complaint he got last year was that it used a non-free JS framework to make the whole thing work. This year he put together an entirely custom library for online survey software, just so this survey could run on it.
For an only occasional Emacs user like myself this survey as a lot of required questions that lack a "None of the above" or "Does not apply to me" option, especially when it comes to packages. I had to just randomly tick something. The results for these questions might be not very useful, because who knows, how many more people like myself filled in the survey. I was also tempted to quit the survey at that point.
> For an only occasional Emacs user like myself this survey as a lot of required questions that lack a "None of the above" or "Does not apply to me" option,
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.
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.
I’ve been using Emacs for 6 years now. But recently it became clear to me that it’s really optimised for Linux and doesn’t work as well on Mac and Windows[1]. On top of that I kept running into performance issues with large files.
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.
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.
> I’ve been using Emacs for 6 years now. But recently it became clear to me that it’s really optimised for Linux and doesn’t work as well on Mac and Windows[1].
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.
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.
> The Emacs devs definitely are biased in favor of free platforms
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.
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.
>This strikes me as shortsighted. Most of us don't have much control over the platform we 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.
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.
What I worry about there is that letting it become too inconvenient to use Free development tools on non-Free platforms will eventually harm the Free Software community's ability to produce competitive Free software, by encouraging a brain drain in the communities that develop Free development tools.
It's not an "eventually" thing. It's happening now, and has been happening for a long time.
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.
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.
Biased is too weak a concept. It is a deliberate, principled choice of FSF/GNU/Emacs to advocate against Windows usage. They are, overall, in favor of some Windows support only in order to show Windows users the benefits and virtues of free software. The ultimate goal is that those users will move away from Windows, not that their Windows experience will be enriched. They knowingly favor these principles over greater success in the Windows world.
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."
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."
AFAIK the balance they try to keep is that users of non-free OSs should not have a better experience than those of free OSs. That doesn't mean they will cripple the experience on non-free OSs, but they won't implement features not implementable, say, on linux nor specifically optimize for non-free OSs.
> On Windows my config doesn’t work at all. I have no idea why. I didn’t have the energy to debug it.
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
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
> doesn’t work as well on Mac
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?
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?
One issue is there are competing forks for mac and it’s not clear which to chose.
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
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
Eli Zaretskii, one of the emacs lead maintainers, develops mostly on a windows platform, if I'm not mistaken. As such it may be worth a shot to report windows-specific issues to their bug tracker.
On Macs I use Aquamacs (http://aquamacs.org/), which seems quite nicely adapted to the macOS environment and I'm comfortable with it. Switching between macOS and Linux is easy for me, but if I have to use a Windows machine, I feel lost most of the time.
During my stint at MS, I used to use emacs on windows and it was ok. I do not remember whether the vanilla variant, the cygwin variant, msys2 or some other custom build, were the best though.
Yeah, I know some people do use it on Windows. But I already felt that I sunk lots of time into debugging my config on multiple occasions, so when on Windows basically nothing from my config worked I lost any will to debug it yet again.
Have you tried emacs-plus[1]? That's what I've been using for years now on macOS and never ran into issues. Opening big files is a different topic though I believe it doesn't work much better on Linux too.
[1] https://github.com/d12frosted/homebrew-emacs-plus
[1] https://github.com/d12frosted/homebrew-emacs-plus
I've been using emacs on mac for decades.
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.
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.
Performance is a killer for me also. I suspect once better tree parsing is implemented many of those issues will be solved. Then it’s just the lack of threading in the gui thread, and a few other nitpicks.
Given that Emacs worked for me alright on a 20MHz 386 30 years ago, I must ask, what in the world are you doing with Emacs that its performance turns out to be inadequate on current hardware?
Probably syntax and long line parsing. I also run in daemon mode.
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.
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.
Made me realize that I use very few packages any more.
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.
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.
> I should probably declare configuration bankruptcy and try starting over from scratch.
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.
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.
Now that Icomplete-vertical is built in I'm not using Vertico any more, if Geiser were built-in (strange that it isn't, considering ob-scheme has deep integration for it) I could probably run Emacs without external packages (though I would really miss consult, embark, and avy).
Looking at the 'view your own result dump' it seems that it didn't record anything past the first page.
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)
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)
> Looking at the 'view your own result dump' it seems that it didn't record anything past the first page.
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...
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...
I use a lot of doom-emacs' defaults, so I'm blissfully ignorant of most of what's going on under the hood, but the ones I am aware of and appreciate most are (in order):
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.
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.
I wouldn't move to ivy today, though ivy is great. I moved on from it to the vertico/orderless/marginalia/consult/corfu type stack and it feels at least equivalent to me, but the implementation is more integrated with built-in Emacs and I think it will have a stronger future. Not that ivy is bad, or a generally inferior user experience.
- dtrt-indent: guess the indentation of the file. Great for collaborating with people
- ws-butler: fix whitespace only on the lines you've changed. Great for collaborating as well
- eglot
- ws-butler: fix whitespace only on the lines you've changed. Great for collaborating as well
- eglot
God-mode is by far my favorite, followed by Magit, Avy and Ace Window (of the same author as Avy).
evil, org-mode, auctex, avy, try… although thinking about it some more, I probably should have included use-package too, and possibly projectile and magit as well.
This survey is just thinly veiled telemetry for big lisp.
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.Wait, I thought that Big Lisp looked down on elisp!
Funny, that.
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.
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.
No. That was decades ago when Gosmacs’s MockLisp was the dominant variant. Still, that was a useful interim phase until GNU EMACS came up to speed. It just wasn’t an acceptable Lisp.
Not nice:
https://emacssurvey.org/2020/ -> 404
http://web.archive.org/web/20201208204421/https://emacssurve...
https://emacssurvey.org/2020/ -> 404
http://web.archive.org/web/20201208204421/https://emacssurve...
The link for the 2020 survey results seems to be https://emacs-survey.netlify.app/2020/
Something seems broken. I took the survey, and when I look at the results, all I see is "missing":
* 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
My results page said this was a known issue under investigation and results had actually been stored.
D'oh! You are right, it's right there below the links.
[deleted]
according to the maintainer:
"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...
"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...
Over on r/emacs the survey author(s) said that there's an issue with export but that the answers are being saved correctly.
It asked me for version numbers. I said Don't know. It refused to accept without major and minor version numbers.
M-x version away
GUI mode; Help -> About Emacs
"emacs -version"
Doesn't your package manager have an equivalent to 'zypper info'/'pacman -Qi'?
I took the survey on my phone and had to google which version comes with Ubuntu 20.04. It seems it is 27.1
That's the same version that is running on my phone (under Termux).
Likewise, I was filling out the survey while not on my work machine where I use emacs.
Just say 18.59
If they'd fix emacs so it would be performant on Windows, natively, I would probably invest time in learning it (and switching OS is not an option here for me at this time). Yes it has problems, packages break all the time, and it is unbelievably slow. I know this is not what most people here might be interested in hearing, but that is a fact of life for me. As it stands right now, it just /feels/ hacky and so, I use VSCode. It gives me 90% of the feature set for 1000% less work.
This was fun! I have never donated before, either - the magit maintainer doesn't get a lot, so I set up a Substack's worth of donations, so to speak ;)
I use emacs daily with doom emacs. Spent a few minutes answering questions then had to drop out because the survey had several required questions regarding packages, discovery and use-of that provides no relevant answers for me to because I don't really stray afar from what doom emacs provides me.
I've been using Emacs for 30 years, and I barely stray outside vanilla. Somewhat embarrassing how little I take advantage of my favorite editor.
[deleted]
So... I've used emacs since '76 and TECO before that. But the survey won't let me enter that as an option, so I guess it's about GNU Emacs only?
Guess they're just not interested in my opinion.
Guess they're just not interested in my opinion.
And then I went to the "about" link to see if I could provide feedback. Author says to send feedback to the email address in his github profile page. But (of course) there is no email on his github profile page which makes me think he really doesn't want to hear about my BS.
Fair enough, I'm not the target market for this survey.
Fair enough, I'm not the target market for this survey.
Glad to see this here; glad to take part.
The US nationality is listed as "American" between "Tuvaluan" and "Ugandan".
Nice joke.
Nice joke.
sorry, I never do surveys that ask about personal info (age, race, sex ...)
Would like to see a link for current/past results.