Lots of discussion about what new users want, but not yet any direct discussion with new users. I think we undervalue things like focus groups when it comes to improving software.
I looked at it years ago and it was “ok”, but I didn’t feel the need to switch, I hated Atom and have used VS Code for a while as my go-to “edit random crap” editor, neither of those mentioned is my main editor, also not emacs.
But I’ve heard some people they liked Sublime because it instantly clicked with them, speed wasn’t really mentioned until later on when compared to IntelliJ IDEA.
People don’t use sublime text because of its “sleek look”
Agreed, this comment in the article really bugged me. When I switched from windows to linux a year or so back I really struggled with text editors. I tried vim and emacs and it felt like I needed to complete a university degree in them to be able to even use the basic functionality. I went with sublime because it was simple and it worked. Yes I had some bad habits trained in by microsoft (but notepad++ is decent imo). Yes a year later I am starting to see that using a keyboard rather than a mouse oriented text editor has major benefits, and that for power users these tools are probably amazing. But I am still not there yet, and still don’t feel strongly inclined to take the plunge.
I couldn’t care less about the aesthetics of the software I use (I am not saying no one cares, just that I don’t). But starting from zero with no idea how any of it works, to being able to reliably use emacs for daily tasks is a long hard journey which is easy to forget for those who travelled it too long ago.
My suggestion if they are really serious about popularity is to make a game. Look at zachtronics games like ExaPunks TIS-100 for the kind of thing I mean. They don’t need to be flashy or pretty. Just set up the user to solve various simple puzzles using the emacs interface and commands, starting with trivial and childish simplicity, and adding new concepts one at a time to gradually increase the complexity of the puzzles. In fact you could even contact Zach Barth and see if he is interested in helping. The vim tutorial is already a lot of the way there, but I was unable to find something similar for emacs and gave up before it even had a chance. As a user making the transition away from windows, and a professional programmer, I am probably exactly the target audience that emacs should be aiming for if they want to gain popularity.
Yes a year later I am starting to see that using a keyboard rather than a mouse oriented text editor has major benefits,
FWIW I believe that there have been some experiments (with experienced users, not neophytes) suggesting that keyboard-only editors aren’t actually faster than using a mouse pointer to move the cursor? Offhand I believe the papers on this showed a modest advantage to using a mouse.
Personally I’m going to continue using vim keybindings because it’s just a subjective comfort thing (I like not having to take my hands away from home row) but it’s enough to make me very reticent to advocate that anybody else spend a huge amount of effort learning the same.
FWIW I believe that there have been some experiments (with experienced users, not neophytes) suggesting that keyboard-only editors aren’t actually faster than using a mouse pointer to move the cursor? Offhand I believe the papers on this showed a modest advantage to using a mouse.
I believe this is often cited by Acme fans, since Acme is… more mouse driven than usual.
If it’s the same study I’ve read about, they did not have anyone included who had actually bothered to learn the keyboard shortcuts ahead of time, so I don’t really think it’s very relevant here; that was more about how to manage an average employee.
This. I like how fast it is, I like the regex search and replace using Python syntax, I like the plugins I’ve added to make several adjacent activities in web development easier.
I don’t use debuggers for the most part - usually the stack trace is enough for me.
It’s interesting to think how such a thing would look like: I think most people would agree that just asking random people “on the street” would be the wrong approach. But if you limit it to a category such as “programmers” you’d have too much bias (“I want what I have”). Focusing on “Interested in Emacs” would probably be a mix of answers of those who are enthusiastically and those who are cautiously curious.
I have the feeling that at best one could figure out what confuses people at first, but is there anything surprising to be found out there? People are surprised by what is different, probably? What do people want? Things to work, usually. Any other results would be quite surprising, if you ask me.
There’s a very interesting pattern whenever UX comes up on Emacs lists - rms desperately wants someone to turn Emacs into a word processor (and better faces is part of that), but the developer and userbase of programmers are puzzled and have no idea what he means or wants from it. Someone half-listening occasionally suggests org, but rms somehow doesn’t know what it is - and it’s probably not what he wants anyways,
Also, it’s hilarious how many improvements to Emacs, be it trivial icon or major C major mode improvements, are blocked by bizarre and ideological interpretations of of the GPL. No small wonder why no one wants to come over to Emacs.
Laying my biases out here, I’ve been an Emacsish user for more than 30 years, but I think that the various licensing machinations of GNU Emacs are probably not the primary reason people don’t want to use Emacs.
I think the implication was that the licensing machinations cause many of the issues that actually keep people away, not that the licensing machinations directly keep people away.
Ignoring the fact that you can use the mouse just as well as in any other application, and the traditional foot pedal, and other clever solutions like god-mode, which makes the default Emacs key binds modal, and evil-mode, which makes them the same as in vi. And did I mention you can just use the mouse?
I agree, I’ve seen RMS comment something to this effect multiple times. Odd that he doesn’t seem to want to put in effort to understand org mode. I think it could be close to what he wants. This post shows a very nice-looking, nearly WYSIWYG setup: https://lepisma.xyz/2017/10/28/ricing-org-mode/
With the amount of friction every proposed changed involves, it’s impressive that anything gets done in emacs development. “We should get icons that don’t suck” ah but licenses (which later turns out, doesn’t really matter, because icons are not code). “Qt5?” no, what if we make GPL4? “what if we make ^C to copy by default?” No, let’s try a welcome dialog or…
Then people act surprised when tree-sitter-emacs development happens outside the emacs mailing list.
With the amount of friction every proposed changed involves, it’s impressive that anything gets done in emacs development.
Indeed, that is the biggest part I got out of this. I’m more surprised there hasn’t been an ecgs fork of emacs that can move forward faster than its “gcc” and show a new way.
What I really want is just a faster editor or one that can do blocking i/o transparently. Having random things block all input while they wait for $THING to do whatever its doing is annoying af.
it’s impressive that anything gets done in emacs development.
It’s notable that the vast majority of development on Emacs happens in 3rd-party libraries. This is mostly on purpose; making everything go into the core would be an enormous bottleneck and waste of time. Of course there are exceptions, but generally when they are more slow-moving that’s OK.
I’ve just started using Spacemacs over Vim so I could get access to Racket mode after I was recommended to try it by fellow Lobsters.
Spacemacs is great! Evil mode works just as I expect it, the actual status lines and such make sense and aren’t completely ugly, SPC-SPC gets you to a fuzzy command search, and as Emacs commands are verbose, most of the time I can totally guess what I want: SPC-SPC-wrap shows me toggle-word-wrap which was indeed what I wanted. When I open a file with a format that is recognized but I don’t have the plugin for, I’m immediately prompted if I want the plugin and away it goes.
I might have been able to hack such an environment together in Vim, but after 6 years of Vim, I never made it even half as usable.
I think it’s 100% OK to treat things like Emacs as base foundations, and then build on top of them. Just like how Debian is a rock solid foundation, and Ubuntu gets built on top. Let the Emacs people be slow and make things work for them and not get all bent out of shape on use numbers. Have those things layered on top be the ones that grow users.
I wonder how long you stick with it. I started using Emacs with Spacemacs, but over time I encountered so many bugs and slowness that I quit.
Then I started just with vanilla Emacs + Evil and gradually added packages. I stole the idea from Spacemacs to bind commands to SPC-something with general.el and which-key. Now I have my own little Spacemacs which is fast and rarely breaks. [1]
Spacemacs is a good gateway drug though. I would newcomers to Emacs definitely recommend to start with Spacemacs, because it shows what is possible with Emacs.
Spacemacs, but over time I encountered so many bugs and slowness that I quit
I had that issue with the main branch, but the devel branch rarely gives me any problems and I experience non of the slowness that plagued the main branch (for me).
Let the Emacs people be slow and make things work for them and not get all bent out of shape on use numbers.
I wonder if those percentages include spacemacs and other layers on top of emacs. I would expect them to include them, as those people are also “using emacs”, maybe less directly, but it’s certainly emacs they’re running.
I think the author of this post is correct in surmising that the proliferation of feature-rich, graphical editors such as Visual Studio Code, Atom, and Sublime Text have a direct correlation to the downturn of Emacs usage in recent years. This might seem a little simplistic, but I think the primary reason for most people not even considering Emacs as their editor comes from the fact that the aforementioned programs are customizable using a language that they are already familiar with, either JS or Python. Choosing between the top two interpreted languages for your editor’s scripting system is going to attract more people than choosing a dialect of Lisp. The fact that Emacs Lisp is one of the most widely-used Lisp dialects tells you something about how popular Lisp is for normal day-to-day programming. It’s not something that most are familiar with, so the learning curve to configuring Emacs is high. Meanwhile, VS Code and Atom let you configure the program with JSON and JavaScript, which is something I believe most developers in the world are familiar with at least on a surface level. If you can get the same features from an editor that is written in a familiar language, why would you choose an editor that requires you to learn something entirely different?
I use Emacs, but only for Org-Mode, and I can tell you with experience that editing the configs takes a bit of getting used to. I mostly use Vim and haven’t really compared it to Emacs here because I don’t feel like the two are easily comparable. Although Vim’s esoteric “VimL” scripting language suffers from the same problems as Emacs, the fact that it can be started up and used with relatively minimal configuration means that a lot of users won’t ever have to write a line of VimL in their lives.
I might be mistaken, but I don’t think that most “feature-rich, graphical editors”-users don’t customize their editor using “JS or Python”, or at least not in the same way as one would customize Emacs. Emacs is changed by being programmed, your init.el or .emacs is an elisp program that initializes the system (setting the customize-system aside). From what I’ve seen of Atom, VS Code and the like is that you have JSON and perhaps a prettier interface. An Emacs user should be encouraged to write their own commands, that’s why the *scratch* buffer is created. It might just be the audience, but I don’t hear of VS Code users writing their own javascript commands to program their environment.
It’s unusual from outside, I guess. And it’s a confusion that’s reflected in the choice of words. People say “Emacs has a lot of plugins”, as that’s what they are used to from other editors. Eclipse, Atom, etc. offer an interface to extend the “core”. The difference is reflected in the sharp divide between users and (plugin) developers. Compare that to Emacs where you “customize” by extending the environment. For that reason the difference “users” and “developers” is more of a gradient, or that’s at least how I see it. And ultimately, Lisp plays a big part in this.
It was through Emacs that I learned to value Free Software, not as in “someone can inspect the code” or “developers can fork it”, but as in “I can control my user environment”, even with it’s warts. Maybe it’s not too popular, or maybe there are just more easy alternatives nowadays, but I know that I won’t compromise on this. That’s also probably why we’re dying :/
Good defaults helps. People like to tweak, but they don’t want to tweak to even get started. There’s also how daunting it can appear. I know with Vim I can get started on any system, and my preferred set of tweaks is less than five lines of simple config statements (Well, Vim is terse and baroque, but it’s basically just setting variables, not anything fancy.). Emacs, there’s a lot to deal with, and a lot has to be done by basically monkey-patching - not very friendly to start with when all you want is say, “keep dired from opening multiple buffers”.
Also, elisp isn’t even a very good Lisp, so even amongst the people who’d be more in-tune with it could be turned off.
Also, elisp isn’t even a very good Lisp, so even amongst the people who’d be more in-tune with it could be turned off.
I agree on the defaults (not that I find vanilla Emacs unusable, either), but I don’t really agree with this. It seem to be a common meme that Elisp is a “bad lisp”, which I guess is not wrong when compared to some Scheme and CL implementations (insofar one understands “bad” as “not as good as”). But it’s still a very enjoyable language, and perhaps it’s just me, but I have a lot more fun working with Elisp that with Python, Haskell or whatever. For all it’s deficiencies it has the strong point of being extremely well integrated into Emacs – because the entire thing is built on top of it.
I also have a lot more fun working with Elisp than most other languages, but I think in a lot of regards it really does fail. Startup being significantly slower than I feel that it could or should be is my personal biggest gripe. These days, people like to talk about Lisp as a functional language, and I know that rms doesn’t subscribe to that but the fact that by default I’m blocked from writing recursive functions is quite frustrating.
It’s true, emacs offers a lot more power, but it requires a time investment in order to really make use of it. Compare that with an editor or IDE where you can get a comfortable environment with just a few clicks. Judging by the popularity of macOS vs Linux for desktop/workstation use, I would imagine the same can be said for editors. Most people want something that “just works” because they’re busy with other problems during the course of their day. These same people probably aren’t all that interested in learning a the Emacs philosophy and getting to work within a Lisp Machine, but there are definitely a good amount of people who are. I don’t think Emacs is going anywhere, but it’s certainly not the best choice for most people anymore.
Most people want something that “just works” because they’re busy with other problems during the course of their day.
This has been my experience. I learned to use Vim when I was in school and had lots of free time to goof around with stuff. I could just as easily have ended up using Emacs, I chose Vim more or less at random.
But these days I don’t even use Vim for programming (I still use Vimwiki for notes) because I simply don’t have time to mess around with my editor or remember what keyboard shortcuts the Python plugin uses versus the Rust plugin, or whatever. I use JetBrains IDEs with the Vim key bindings plugin, and that’s pretty much all the customization I do. Plus JB syncs my plugins and settings across different IDEs and even different machines, with no effort on my part.
So, in some sense, I “sold out” and I certainly sacrificed some freedom. But it was a calculated and conscious trade-off because I have work to do and (very) finite time in which to do it.
I can’t find it now, but someone notes something along those lines in the thread, saying that Emacs doesn’t offer “instant gratifications”, but requires effort to get into. And at some point it’s just a philosophical discussion on what is better. I, who has invested the time and effort, certainly think it is worth it, and believe that it’s the case for many others too.
IDEs are actually quite complicated and come with their own sets of quirks that people have to learn. I was very comfortable with VS Code because I’ve been using various Microsoft IDE’s through the years, and the UI concepts have been quite consistent among them. But a new user still needs to internalize the project view, the editing view, the properties view, and the runtime view, just as I as a new user of Emacs had to internalize its mechanisms almost 30 years ago.
It’s “easier” now because of the proliferation of guides and tutorials, and also that GUI interfaces are probably inheritably more explorable than console ones. That said, don’t underestimate the power of M-x apropos when trying to find some functionality in Emacs…
Yeah, use plugins in every editor, text or GUI. I’ve never written a plugin in my life, nor will I. I’m trying to achieve a goal, not yak-shave a plugin alone the way.
Writing a new major mode (or, hell, even a new minor mode) is absolutely a detour. I used emacs for the better part of a decade and did each several times.
I eventually got tired of it, and just went to what had the better syntax support for my primary language (rust) at the time (vim). I already used evil so the switch was easy enough.
I use VSCode with the neovim backend these days because the language server support is better (mostly: viewing docstrings from RLS is nicer than from a panel in neovim), and getting set up for a new language is easier than vim/emacs.
It’s not too surprising for me that between automating a task by writing a command and starting an entire new project that the line of a detour can be drawn. But even still, I think it’s not that clear. One might start by writing a few commands, and then bundle them together in a minor mode. That’s little more than creating a map and writing a bare minimal define-minor-mode.
In general, it’s just like any automation, imo. It can help you in the long term, but it can get out of hand.
Although I tend to use Vim, I actually have configured Atom with custom JS and CSS when I’ve used it (it’s not just JSON; you can easily write your own JS that runs in the same process space as the rest of the editor, similar to Elisp and Emacs). I don’t think the divide is as sharp as you might think; I think that Emacs users are more likely to want to configure their editors heavily than Atom or VSCode users (because, after all, Elisp configuration is really the main draw of Emacs — without Elisp, Emacs would just be an arcane, needlessly difficult to use text editor); since Atom and VSCode are also just plain old easy-to-use text editors out of the box, with easy built-in package management, many Atom/VSCode users don’t find the need to write much code, especially at first.
It’s quite easy to extend Atom and VSCode with JS/CSS, really. That was one of the selling points of Atom when it first launched: a modern hackable text editor. VSCode is similar, but appears to have become more popular by being more performant.
but I think the primary reason for most people not even considering Emacs as their editor comes from the fact that the aforementioned programs are customizable using a language that they are already familiar with, either JS or Python
I disagree.
I think most people care that a healthy extension ecosystem that just works and is easy to tap in to is there - they basically never really want to have to create a plugin. To achieve that, you need to attract people to create plugins, which is where your point comes in.
As a thought experiment, if I’m a developer who’s been using VS Code or some such for the longest time, where it’s trivial to add support for new languages through an almost one-click extension system, what’s the push that has me looking for new editors and new pastures?
I can see a few angles myself - emacs or vim are definitely snappier, for instance.
Right: VS Code and Sublime Text aren’t nearly as featureful as Emacs, and they change UIs without warning, making muscle memory a liability instead of an asset. They win on marketing and visual flash for their popularity, which Emacs currently doesn’t have, but Emacs is what you make of it, and rewards experience.
I don’t know that emacs will see a resurgence in popularity, and that’s ok. If you take the time to learn it, it really is an amazing environment. It’s a curses interface, but it’s a GUI. Org-mode + babel is basically like a lightweight jupyter notebook that can be trivially exported to PDF. tramp mode is a much better remote file editing technique. It also, by the way, provides a great programming environment for the languages I typically use.
I agree wholeheartedly. Emacs might not be as good an editor as vim (for some values of good) but it’s a hell of a great environment.
The other day I had to do some fairly complex renaming of files in a directory (think “replace string with other string”), in a TUI environment. I could have done multiple mv commands. I could have come up with a bash script. What I did was fire up dired, enter edit mode, make my changes in the directory listing that was now editable text and commit the changes.
My proposal, simple but I think super effective: remove almost all default key bindings, but add some extra steps in the UX flow when installing packages interactively to be prompted to provide key bindings for important things.
Given emacs pitch as a super extensible thing, I really think that the default key bindings on almost every plugin do massive disservices for stuff, especially in the age of M-x. It would also introduce verbs and nouns to newer users in context
I am surprised to see that nobody has mentionned neovim’s approach, which is to make building GUIs very cheap and easy thanks to an RPC protocol. This has resulted in dozens of GUIs being written, for all platforms, in any language, and even embedding neovim in various other pieces of software such as VSCode, QtCreator, Firefox….
This would solve multiple problems: people who have different ideas about what emacs should look like can use different GUIs, and the developpers of “emacs core” could offload the GUI work on other developpers. Plugins could also be written in languages that are not elisp, which I’ve heard is not as bad as Vimscript but still not a great language to program in.
Yes, and vim also has a client/server feature that you can use to build GUIs (see athame and pterosaur). But in my opinion, neither emacs’ nor vim’s client/server protocol make building GUIs as easy as Neovim’s protocol (which really just requires you to have a messagepack library, and even that is quite trivial to write).
Plugins could also be written in languages that are not elisp, which I’ve heard is not as bad as Vimscript but still not a great language to program in.
Elisp is miles ahead of vimscript and better than most other languages that vim plugins are written in using the RPC mechanism. I think the appeal of the RPC is directly correlated to how bad vimscript is.
Rather than an RPC, another angle is to embed a runtime that supports multiple languages, such as Guile, which allows you to code in Elisp, Scheme, JS, Lua, and more. Some people have worked on integrating this with Emacs, but it’s still pretty rudimentary.
I think the appeal of the RPC is directly correlated to how bad vimscript is.
RPC also allows plugin to execute in a separate process, thus preventing them from blocking all of the editor when performing blocking actions. This is a problem Vim has had for a long time and which only got fixed recently. I’ve heard Emacs also suffered from this issue.
Rather than an RPC, another angle is to embed a runtime that supports multiple languages, such as Guile
Yeah, I’ve heard about Guile Emacs but last time I looked at it it seemed to be dead (the Emacs community wasn’t interested in moving to it). Has the situation improved?
Emacs is great, and in a modern configuration, like Spacemacs, it’s even greater. It’s a uniquely powerful application or environment, more programmable and configurable than anything else in it’s league and in Lisp (!!) which is also experiencing a renaissance with Clojure and Racket. Despite its age and idiosyncrasies, emacs is a breath of fresh air in world of increasingly dumbed-down GUIs and opaquely complex uncustomizable environments.
But it certainly is showing its age and could really use rethink of, well almost everything. The problem is, can that even be done without breaking the zillions of packages that make it great today? Perry Metzger gave a talk[1] about this question at 2019 Emacscon entitled “Emacs, the Editor for the next 40 years” that charts a path forward, although not all that clearly. For improved performance, there is now possibility of compiling elisp to native code[2], and although it’ll need a bit more polish, it actually works today! RMS himself in the LWN article points out that the X display code needs a complete overhaul “by an expert”, and I would add that we should take that opportunity to generalize it for Wayland. Who will step up to that herculean task?
Meanwhile, for its fans emacs today, with all its warts, provides something that nothing else can do, and I think that’s more important than popularity.
My girlfriend wanted to learn to build webpages and insisted she must use the same editor I use.
I installed spacemacs, and she likes it.
She said the key combos were slightly more complicated than MS Office, but not much.
I’d never tried spacemacs before, and ended up stealing a bunch of useful config for my own use.
emacs is “a crappy lisp machine clone” as a coworker recently said, and that extensibility is the real magic. I’ve built eshell pipelines that mixed shell commands, elisp, and existing buffers, it’s amazing what you can do.
I moved to Emacs last year because I heard at a conference that the Freeswitch guys use it, and so I decided to give it a try. It stuck with me and now I love it!
Personally, as a new user, I have to say for me the appeal was that it wasn’t like other editors. If it was more like VS Code or others I wouldn’t use it.
Lots of discussion about what new users want, but not yet any direct discussion with new users. I think we undervalue things like focus groups when it comes to improving software.
It doesn’t help when they are wrong in their assumptions, like :
People don’t use sublime text because of its “sleek look”. It is really ugly compared to VS Code. People use it because it’s fast.
“ugly” is a subjective term.
I looked at it years ago and it was “ok”, but I didn’t feel the need to switch, I hated Atom and have used VS Code for a while as my go-to “edit random crap” editor, neither of those mentioned is my main editor, also not emacs.
But I’ve heard some people they liked Sublime because it instantly clicked with them, speed wasn’t really mentioned until later on when compared to IntelliJ IDEA.
Agreed, this comment in the article really bugged me. When I switched from windows to linux a year or so back I really struggled with text editors. I tried vim and emacs and it felt like I needed to complete a university degree in them to be able to even use the basic functionality. I went with sublime because it was simple and it worked. Yes I had some bad habits trained in by microsoft (but notepad++ is decent imo). Yes a year later I am starting to see that using a keyboard rather than a mouse oriented text editor has major benefits, and that for power users these tools are probably amazing. But I am still not there yet, and still don’t feel strongly inclined to take the plunge.
I couldn’t care less about the aesthetics of the software I use (I am not saying no one cares, just that I don’t). But starting from zero with no idea how any of it works, to being able to reliably use emacs for daily tasks is a long hard journey which is easy to forget for those who travelled it too long ago.
My suggestion if they are really serious about popularity is to make a game. Look at zachtronics games like ExaPunks TIS-100 for the kind of thing I mean. They don’t need to be flashy or pretty. Just set up the user to solve various simple puzzles using the emacs interface and commands, starting with trivial and childish simplicity, and adding new concepts one at a time to gradually increase the complexity of the puzzles. In fact you could even contact Zach Barth and see if he is interested in helping. The vim tutorial is already a lot of the way there, but I was unable to find something similar for emacs and gave up before it even had a chance. As a user making the transition away from windows, and a professional programmer, I am probably exactly the target audience that emacs should be aiming for if they want to gain popularity.
FWIW I believe that there have been some experiments (with experienced users, not neophytes) suggesting that keyboard-only editors aren’t actually faster than using a mouse pointer to move the cursor? Offhand I believe the papers on this showed a modest advantage to using a mouse.
Personally I’m going to continue using vim keybindings because it’s just a subjective comfort thing (I like not having to take my hands away from home row) but it’s enough to make me very reticent to advocate that anybody else spend a huge amount of effort learning the same.
I believe this is often cited by Acme fans, since Acme is… more mouse driven than usual.
If it’s the same study I’ve read about, they did not have anyone included who had actually bothered to learn the keyboard shortcuts ahead of time, so I don’t really think it’s very relevant here; that was more about how to manage an average employee.
Pass. Could be, but it’s been a while and goodness only knows. I think what I read used experienced programmers.
At any rate: a vague impression that there might be fairly hard evidence for ¬A is enough to make me not run around advocating A to people.
This. I like how fast it is, I like the regex search and replace using Python syntax, I like the plugins I’ve added to make several adjacent activities in web development easier.
I don’t use debuggers for the most part - usually the stack trace is enough for me.
It’s interesting to think how such a thing would look like: I think most people would agree that just asking random people “on the street” would be the wrong approach. But if you limit it to a category such as “programmers” you’d have too much bias (“I want what I have”). Focusing on “Interested in Emacs” would probably be a mix of answers of those who are enthusiastically and those who are cautiously curious.
I have the feeling that at best one could figure out what confuses people at first, but is there anything surprising to be found out there? People are surprised by what is different, probably? What do people want? Things to work, usually. Any other results would be quite surprising, if you ask me.
There’s a very interesting pattern whenever UX comes up on Emacs lists - rms desperately wants someone to turn Emacs into a word processor (and better faces is part of that), but the developer and userbase of programmers are puzzled and have no idea what he means or wants from it. Someone half-listening occasionally suggests org, but rms somehow doesn’t know what it is - and it’s probably not what he wants anyways,
Also, it’s hilarious how many improvements to Emacs, be it trivial icon or major C major mode improvements, are blocked by bizarre and ideological interpretations of of the GPL. No small wonder why no one wants to come over to Emacs.
Laying my biases out here, I’ve been an Emacsish user for more than 30 years, but I think that the various licensing machinations of GNU Emacs are probably not the primary reason people don’t want to use Emacs.
I think the implication was that the licensing machinations cause many of the issues that actually keep people away, not that the licensing machinations directly keep people away.
More blocks the resolution for the issues that keep people away, but same energy.
The primary reason is probably that most humans have only five digits per hand, whereas Emacs is clearly designed for octopus.
Ignoring the fact that you can use the mouse just as well as in any other application, and the traditional foot pedal, and other clever solutions like god-mode, which makes the default Emacs key binds modal, and evil-mode, which makes them the same as in vi. And did I mention you can just use the mouse?
My comment is light-hearted, perhaps yours is too :)
I agree, I’ve seen RMS comment something to this effect multiple times. Odd that he doesn’t seem to want to put in effort to understand org mode. I think it could be close to what he wants. This post shows a very nice-looking, nearly WYSIWYG setup: https://lepisma.xyz/2017/10/28/ricing-org-mode/
With the amount of friction every proposed changed involves, it’s impressive that anything gets done in emacs development. “We should get icons that don’t suck” ah but licenses (which later turns out, doesn’t really matter, because icons are not code). “Qt5?” no, what if we make GPL4? “what if we make ^C to copy by default?” No, let’s try a welcome dialog or…
Then people act surprised when
tree-sitter-emacsdevelopment happens outside the emacs mailing list.Indeed, that is the biggest part I got out of this. I’m more surprised there hasn’t been an ecgs fork of emacs that can move forward faster than its “gcc” and show a new way.
What I really want is just a faster editor or one that can do blocking i/o transparently. Having random things block all input while they wait for $THING to do whatever its doing is annoying af.
It’s notable that the vast majority of development on Emacs happens in 3rd-party libraries. This is mostly on purpose; making everything go into the core would be an enormous bottleneck and waste of time. Of course there are exceptions, but generally when they are more slow-moving that’s OK.
I’ve just started using Spacemacs over Vim so I could get access to Racket mode after I was recommended to try it by fellow Lobsters.
Spacemacs is great! Evil mode works just as I expect it, the actual status lines and such make sense and aren’t completely ugly,
SPC-SPCgets you to a fuzzy command search, and as Emacs commands are verbose, most of the time I can totally guess what I want:SPC-SPC-wrapshows metoggle-word-wrapwhich was indeed what I wanted. When I open a file with a format that is recognized but I don’t have the plugin for, I’m immediately prompted if I want the plugin and away it goes.I might have been able to hack such an environment together in Vim, but after 6 years of Vim, I never made it even half as usable.
I think it’s 100% OK to treat things like Emacs as base foundations, and then build on top of them. Just like how Debian is a rock solid foundation, and Ubuntu gets built on top. Let the Emacs people be slow and make things work for them and not get all bent out of shape on use numbers. Have those things layered on top be the ones that grow users.
Same-ish but with doom-emacs, which is lighter (I think?) and does all of the above.
I wonder how long you stick with it. I started using Emacs with Spacemacs, but over time I encountered so many bugs and slowness that I quit.
Then I started just with vanilla Emacs + Evil and gradually added packages. I stole the idea from Spacemacs to bind commands to
SPC-somethingwithgeneral.elandwhich-key. Now I have my own little Spacemacs which is fast and rarely breaks. [1]Spacemacs is a good gateway drug though. I would newcomers to Emacs definitely recommend to start with Spacemacs, because it shows what is possible with Emacs.
[1] Most of the configuration, some language-specific parts are in different files: https://github.com/danieldk/nix-home/blob/master/cfg/emacs.nix
I had that issue with the main branch, but the devel branch rarely gives me any problems and I experience non of the slowness that plagued the main branch (for me).
I’ve been using spacemacs for about 4 years. WFM.
What does hitting
Tabdo for you in your Spacemacs setup? Coming from Vim, having it often do nothing drives me batty.I wonder if those percentages include spacemacs and other layers on top of emacs. I would expect them to include them, as those people are also “using emacs”, maybe less directly, but it’s certainly emacs they’re running.
I think the author of this post is correct in surmising that the proliferation of feature-rich, graphical editors such as Visual Studio Code, Atom, and Sublime Text have a direct correlation to the downturn of Emacs usage in recent years. This might seem a little simplistic, but I think the primary reason for most people not even considering Emacs as their editor comes from the fact that the aforementioned programs are customizable using a language that they are already familiar with, either JS or Python. Choosing between the top two interpreted languages for your editor’s scripting system is going to attract more people than choosing a dialect of Lisp. The fact that Emacs Lisp is one of the most widely-used Lisp dialects tells you something about how popular Lisp is for normal day-to-day programming. It’s not something that most are familiar with, so the learning curve to configuring Emacs is high. Meanwhile, VS Code and Atom let you configure the program with JSON and JavaScript, which is something I believe most developers in the world are familiar with at least on a surface level. If you can get the same features from an editor that is written in a familiar language, why would you choose an editor that requires you to learn something entirely different?
I use Emacs, but only for Org-Mode, and I can tell you with experience that editing the configs takes a bit of getting used to. I mostly use Vim and haven’t really compared it to Emacs here because I don’t feel like the two are easily comparable. Although Vim’s esoteric “VimL” scripting language suffers from the same problems as Emacs, the fact that it can be started up and used with relatively minimal configuration means that a lot of users won’t ever have to write a line of VimL in their lives.
I might be mistaken, but I don’t think that most “feature-rich, graphical editors”-users don’t customize their editor using “JS or Python”, or at least not in the same way as one would customize Emacs. Emacs is changed by being programmed, your
init.elor.emacsis an elisp program that initializes the system (setting the customize-system aside). From what I’ve seen of Atom, VS Code and the like is that you have JSON and perhaps a prettier interface. An Emacs user should be encouraged to write their own commands, that’s why the*scratch*buffer is created. It might just be the audience, but I don’t hear of VS Code users writing their own javascript commands to program their environment.It’s unusual from outside, I guess. And it’s a confusion that’s reflected in the choice of words. People say “Emacs has a lot of plugins”, as that’s what they are used to from other editors. Eclipse, Atom, etc. offer an interface to extend the “core”. The difference is reflected in the sharp divide between users and (plugin) developers. Compare that to Emacs where you “customize” by extending the environment. For that reason the difference “users” and “developers” is more of a gradient, or that’s at least how I see it. And ultimately, Lisp plays a big part in this.
It was through Emacs that I learned to value Free Software, not as in “someone can inspect the code” or “developers can fork it”, but as in “I can control my user environment”, even with it’s warts. Maybe it’s not too popular, or maybe there are just more easy alternatives nowadays, but I know that I won’t compromise on this. That’s also probably why we’re dying :/
Good defaults helps. People like to tweak, but they don’t want to tweak to even get started. There’s also how daunting it can appear. I know with Vim I can get started on any system, and my preferred set of tweaks is less than five lines of simple config statements (Well, Vim is terse and baroque, but it’s basically just setting variables, not anything fancy.). Emacs, there’s a lot to deal with, and a lot has to be done by basically monkey-patching - not very friendly to start with when all you want is say, “keep dired from opening multiple buffers”.
Also, elisp isn’t even a very good Lisp, so even amongst the people who’d be more in-tune with it could be turned off.
I agree on the defaults (not that I find vanilla Emacs unusable, either), but I don’t really agree with this. It seem to be a common meme that Elisp is a “bad lisp”, which I guess is not wrong when compared to some Scheme and CL implementations (insofar one understands “bad” as “not as good as”). But it’s still a very enjoyable language, and perhaps it’s just me, but I have a lot more fun working with Elisp that with Python, Haskell or whatever. For all it’s deficiencies it has the strong point of being extremely well integrated into Emacs – because the entire thing is built on top of it.
I also have a lot more fun working with Elisp than most other languages, but I think in a lot of regards it really does fail. Startup being significantly slower than I feel that it could or should be is my personal biggest gripe. These days, people like to talk about Lisp as a functional language, and I know that rms doesn’t subscribe to that but the fact that by default I’m blocked from writing recursive functions is quite frustrating.
It’s true, emacs offers a lot more power, but it requires a time investment in order to really make use of it. Compare that with an editor or IDE where you can get a comfortable environment with just a few clicks. Judging by the popularity of macOS vs Linux for desktop/workstation use, I would imagine the same can be said for editors. Most people want something that “just works” because they’re busy with other problems during the course of their day. These same people probably aren’t all that interested in learning a the Emacs philosophy and getting to work within a Lisp Machine, but there are definitely a good amount of people who are. I don’t think Emacs is going anywhere, but it’s certainly not the best choice for most people anymore.
This has been my experience. I learned to use Vim when I was in school and had lots of free time to goof around with stuff. I could just as easily have ended up using Emacs, I chose Vim more or less at random.
But these days I don’t even use Vim for programming (I still use Vimwiki for notes) because I simply don’t have time to mess around with my editor or remember what keyboard shortcuts the Python plugin uses versus the Rust plugin, or whatever. I use JetBrains IDEs with the Vim key bindings plugin, and that’s pretty much all the customization I do. Plus JB syncs my plugins and settings across different IDEs and even different machines, with no effort on my part.
So, in some sense, I “sold out” and I certainly sacrificed some freedom. But it was a calculated and conscious trade-off because I have work to do and (very) finite time in which to do it.
I can’t find it now, but someone notes something along those lines in the thread, saying that Emacs doesn’t offer “instant gratifications”, but requires effort to get into. And at some point it’s just a philosophical discussion on what is better. I, who has invested the time and effort, certainly think it is worth it, and believe that it’s the case for many others too.
IDEs are actually quite complicated and come with their own sets of quirks that people have to learn. I was very comfortable with VS Code because I’ve been using various Microsoft IDE’s through the years, and the UI concepts have been quite consistent among them. But a new user still needs to internalize the project view, the editing view, the properties view, and the runtime view, just as I as a new user of Emacs had to internalize its mechanisms almost 30 years ago.
It’s “easier” now because of the proliferation of guides and tutorials, and also that GUI interfaces are probably inheritably more explorable than console ones. That said, don’t underestimate the power of
M-x aproposwhen trying to find some functionality in Emacs…Yeah, use plugins in every editor, text or GUI. I’ve never written a plugin in my life, nor will I. I’m trying to achieve a goal, not yak-shave a plugin alone the way.
That’s my point. Emacs offers the possibility that extending the environment isn’t a detour but a method to achieve your goals.
Writing a new major mode (or, hell, even a new minor mode) is absolutely a detour. I used emacs for the better part of a decade and did each several times.
I eventually got tired of it, and just went to what had the better syntax support for my primary language (rust) at the time (vim). I already used evil so the switch was easy enough.
I use VSCode with the neovim backend these days because the language server support is better (mostly: viewing docstrings from RLS is nicer than from a panel in neovim), and getting set up for a new language is easier than vim/emacs.
It’s not too surprising for me that between automating a task by writing a command and starting an entire new project that the line of a detour can be drawn. But even still, I think it’s not that clear. One might start by writing a few commands, and then bundle them together in a minor mode. That’s little more than creating a map and writing a bare minimal
define-minor-mode.In general, it’s just like any automation, imo. It can help you in the long term, but it can get out of hand.
Although I tend to use Vim, I actually have configured Atom with custom JS and CSS when I’ve used it (it’s not just JSON; you can easily write your own JS that runs in the same process space as the rest of the editor, similar to Elisp and Emacs). I don’t think the divide is as sharp as you might think; I think that Emacs users are more likely to want to configure their editors heavily than Atom or VSCode users (because, after all, Elisp configuration is really the main draw of Emacs — without Elisp, Emacs would just be an arcane, needlessly difficult to use text editor); since Atom and VSCode are also just plain old easy-to-use text editors out of the box, with easy built-in package management, many Atom/VSCode users don’t find the need to write much code, especially at first.
It’s quite easy to extend Atom and VSCode with JS/CSS, really. That was one of the selling points of Atom when it first launched: a modern hackable text editor. VSCode is similar, but appears to have become more popular by being more performant.
I disagree.
I think most people care that a healthy extension ecosystem that just works and is easy to tap in to is there - they basically never really want to have to create a plugin. To achieve that, you need to attract people to create plugins, which is where your point comes in.
As a thought experiment, if I’m a developer who’s been using VS Code or some such for the longest time, where it’s trivial to add support for new languages through an almost one-click extension system, what’s the push that has me looking for new editors and new pastures?
I can see a few angles myself - emacs or vim are definitely snappier, for instance.
EDIT: I just spotted Hashicorp are officially contributing to the Terraform VS Code extension. At this point I wonder if VS Code’s extension library essentially has critical mass.
Right: VS Code and Sublime Text aren’t nearly as featureful as Emacs, and they change UIs without warning, making muscle memory a liability instead of an asset. They win on marketing and visual flash for their popularity, which Emacs currently doesn’t have, but Emacs is what you make of it, and rewards experience.
I don’t know that emacs will see a resurgence in popularity, and that’s ok. If you take the time to learn it, it really is an amazing environment. It’s a curses interface, but it’s a GUI. Org-mode + babel is basically like a lightweight jupyter notebook that can be trivially exported to PDF. tramp mode is a much better remote file editing technique. It also, by the way, provides a great programming environment for the languages I typically use.
I agree wholeheartedly. Emacs might not be as good an editor as vim (for some values of good) but it’s a hell of a great environment.
The other day I had to do some fairly complex renaming of files in a directory (think “replace string with other string”), in a TUI environment. I could have done multiple
mvcommands. I could have come up with a bash script. What I did was fire updired, enter edit mode, make my changes in the directory listing that was now editable text and commit the changes.Oh, and without
magitI’d not be using git.Emacs is a much better editor than Vim, indeed.
My proposal, simple but I think super effective: remove almost all default key bindings, but add some extra steps in the UX flow when installing packages interactively to be prompted to provide key bindings for important things.
Given emacs pitch as a super extensible thing, I really think that the default key bindings on almost every plugin do massive disservices for stuff, especially in the age of M-x. It would also introduce verbs and nouns to newer users in context
Emacs is as idea that can blossom in other forms
https://github.com/remacs/remacs/blob/master/README.md
Pushing on that idea brings you to the realm of, “Tailoring your tools by programming them,” and that is something that will never go away.
I am surprised to see that nobody has mentionned neovim’s approach, which is to make building GUIs very cheap and easy thanks to an RPC protocol. This has resulted in dozens of GUIs being written, for all platforms, in any language, and even embedding neovim in various other pieces of software such as VSCode, QtCreator, Firefox….
This would solve multiple problems: people who have different ideas about what emacs should look like can use different GUIs, and the developpers of “emacs core” could offload the GUI work on other developpers. Plugins could also be written in languages that are not elisp, which I’ve heard is not as bad as Vimscript but still not a great language to program in.
But what if someone were to write a GUI that wasnt GPL3+ licensed?
Let’s write the AGPLv2 to make sure this doesn’t happen!
Emacs-server is already a thing, but I don’t know if it’s used as a central hub for new “skins” of Emacs.
Yes, and vim also has a client/server feature that you can use to build GUIs (see athame and pterosaur). But in my opinion, neither emacs’ nor vim’s client/server protocol make building GUIs as easy as Neovim’s protocol (which really just requires you to have a messagepack library, and even that is quite trivial to write).
Elisp is miles ahead of vimscript and better than most other languages that vim plugins are written in using the RPC mechanism. I think the appeal of the RPC is directly correlated to how bad vimscript is.
Rather than an RPC, another angle is to embed a runtime that supports multiple languages, such as Guile, which allows you to code in Elisp, Scheme, JS, Lua, and more. Some people have worked on integrating this with Emacs, but it’s still pretty rudimentary.
RPC also allows plugin to execute in a separate process, thus preventing them from blocking all of the editor when performing blocking actions. This is a problem Vim has had for a long time and which only got fixed recently. I’ve heard Emacs also suffered from this issue.
Yeah, I’ve heard about Guile Emacs but last time I looked at it it seemed to be dead (the Emacs community wasn’t interested in moving to it). Has the situation improved?
Emacs is great, and in a modern configuration, like Spacemacs, it’s even greater. It’s a uniquely powerful application or environment, more programmable and configurable than anything else in it’s league and in Lisp (!!) which is also experiencing a renaissance with Clojure and Racket. Despite its age and idiosyncrasies, emacs is a breath of fresh air in world of increasingly dumbed-down GUIs and opaquely complex uncustomizable environments.
But it certainly is showing its age and could really use rethink of, well almost everything. The problem is, can that even be done without breaking the zillions of packages that make it great today? Perry Metzger gave a talk[1] about this question at 2019 Emacscon entitled “Emacs, the Editor for the next 40 years” that charts a path forward, although not all that clearly. For improved performance, there is now possibility of compiling elisp to native code[2], and although it’ll need a bit more polish, it actually works today! RMS himself in the LWN article points out that the X display code needs a complete overhaul “by an expert”, and I would add that we should take that opportunity to generalize it for Wayland. Who will step up to that herculean task?
Meanwhile, for its fans emacs today, with all its warts, provides something that nothing else can do, and I think that’s more important than popularity.
[1] https://media.emacsconf.org/2019/26.html
[2] http://akrl.sdf.org/gccemacs.html
My girlfriend wanted to learn to build webpages and insisted she must use the same editor I use. I installed spacemacs, and she likes it. She said the key combos were slightly more complicated than MS Office, but not much. I’d never tried spacemacs before, and ended up stealing a bunch of useful config for my own use.
emacs is “a crappy lisp machine clone” as a coworker recently said, and that extensibility is the real magic. I’ve built eshell pipelines that mixed shell commands, elisp, and existing buffers, it’s amazing what you can do.
I moved to Emacs last year because I heard at a conference that the Freeswitch guys use it, and so I decided to give it a try. It stuck with me and now I love it!
Personally, as a new user, I have to say for me the appeal was that it wasn’t like other editors. If it was more like VS Code or others I wouldn’t use it.