I don’t know. I read the whole article and it seems the suggestions boil down to emacs needing to be more “modern” by defaulting to dark mode, making color theming easier, changing right click behavior, the menus, and changing the shortcuts. And the author of the article would like the development process to be more “modern.”
Emacs is one of the most successful text editors of all time if not the most successful. It is widely used for a staggering array of tasks.
It is over 40 years old.
When I see a highly successful 40+ year old piece of software, my first instinct isn’t to ask what the people behind it can learn from me but what I can learn from them.
I’m not saying the editor can not be improved. But I think the bar is much higher than this. It’s not an insult to say something like emacs is not “modern.” Of course it’s not. And changing the colors? The shortcuts that have worked for decades? Please.
If someone thinks emacs will be more successful with these cosmetic changes they are welcome to fork it since this is one of the earliest open source programs. Code talks, a bunch of people opining on a mailing list is pretty worthless in comparison.
That's great and all, but people who are learning emacs for the first time don't know or care that it's one of the most successful text editors or that it's been around for 40 years. They care about being able to write code effectively. And emacs doesn't let users write code effectively by modern standards. Sure, after boatloads of configuration and tinkering it does, but it's unclear if it's worth it.
Forking it is also missing the point. There's plenty of forks with dark coloring schemes and predefined packages. Spacemacs, Doom emacs, etc. The issue is that most people hear about emacs and try to download emacs, not Spacemacs, not Doom. They're then greeted by an unfriendly UI and confusing commands and dammit it doesn't even autocomplete JavaScript by default.
Dark color schemes and proper right click functionality might seen dumb, but they're one easy step towards making emacs seem like an editor for the 21st century and not something your dad used on a Lisp machine in the 80's.
Yeah I think this is on point. The core maintainers are always kind of resisting changing things to more sane defaults, which is a pity.
I recently had the experience of a friend of mine, a data scientist, tell me he tried to use emacs but just couldn’t get it to work. When I asked how he installed it, he was like “well I just downloaded it, and started tinkering a bit with my config”. After which he just ditched it, he accepted that the learning curve was just to steep.
The idea that there are these whole starter packs never crossed his mind. I referred him to a few, and he suddenly got much more productive and has been a happy emacs user ever since.
Moral of the story: at the very least, users should be made aware of these starter packs much more prominently when downloading or installing emacs. Alternatively, fix the defaults.
Great. Now where is the starter pack. Better with some lisp in a box etc. as well. I use lisp download with Mac because at least the key I know of. No strange key combination.
I don't know dude, I've had new grads recently wholesale switch to Emacs just after watching me work for five minutes. "Holy crap, why are you editing these programs so much faster than me?"
Completely agree that out-of-the-box Emacs experience is NOT where it's at. I have twenty years invested in tweaking it to minimize keystrokes and operate faster for my use cases. Just remember that Emacs is not actually an editor, it's a Lisp Machine OS you can use to build an editor out of parts
Also keep in mind that alternate distros like Spacemacs are the way Emacs has to evolve, because making drastic structural changes to defaults would break so many user scripts and packages -- the things that provide most of the long-term value proposition of using Emacs in the first place.
Who cares if new people use it or if it looks modern? It’s working well for the people who want it. Not every piece of software has to be everything to everyone.
Well I care, and so should anyone who would like to see Emacs live on for another 40 years. There will be major new areas of innovation, that will require massive amounts of work, and without an energetic and large community Emacs will not be able to adapt.
Well, as sad as it is for someone like me, who lives and breathes Emacs, there are already signs showing. There's still no decent support for C++, even in community. If you have a patience to bash together a number of elisp packages and write some extra config to paper over the idiosyncrasies of your project, then sure, you'll get something mostly working. But then just downloading Visual Studio will get you 90% there.
There's support for language servers (and I consider the existence of LSP to be a new hope for Emacs and Vim to stay relevant in the future), but it's arguably so-so.
As good as the Emacs community is, it still has pretty limited amount of time and manpower to throw at problems. I feel the wider development world starts to outpace this capacity.
An interesting thing that often gets forgotten or missed is that Emacs doesn't depend on a conventional TTY to run. It's already capable of displaying images either in separate buffers or inline.
From Gary's talk there, my thoughts would be that a number of the features he's put in there would:
a) be potentially better-served as CLI tools instead of baked directly into the IDE, with well-defined inputs and outputs. I have no problem imagining use cases for e.g. the crash navigation stuff outside of an editor (perhaps as part of an error-handling dashboard).
b) likely already be possible to build in non-terminal versions of Emacs, without having to design your own terminal and editor from scratch.
By no means do I think Emacs is a perfect editor, but I'm also very cautious when pondering "do we rebuild from scratch"-type questions. I'm always keeping my eye on other editors and IDEs, and with varying levels of difficulty, I haven't really come across too many useful things that wouldn't be possible to do within the current Emacs/Elisp environment. Awkward, maybe.
It’s not that black and white. A simple hint when installing or downloading, “hey did you know that there are these starter packs?” would already do wonders.
It’s not that people are suggesting emacs tries to be everything to everyone; heck, by pure virtue of its extensibility, emacs is actually the one editor that could potentially be everything to everyone. But a simple startup screen, “hey, it looks like this is your first time using emacs. what kind of defaults would you like?” would do wonders and existing users would be entirely unaffected.
> A simple hint when installing or downloading, “hey did you know that there are these starter packs?” would already do wonders.
Automating the Starter-Pack-Installation at virgin start and adding one or two out of the box would be better. Many people are not downloading emacs directly. On Linux you go through your destribution.
If new people don't use it, both its user base and developer list will monotonically decrease until both reach zero which may happen sooner than it could've been otherwise.
I think that's okay. I see that many younger colleagues and friends no longer use Emacs or Vim, preferring editors with Textmate heritage (sublime, vs code and so on).
I think the middle ground during the transition would be the worst of both worlds and there is no shame to no longer be on the top if the times change.
> That's great and all, but people who are learning emacs for the first time don't know or care that it's one of the most successful text editors or that it's been around for 40 years
I don't think this is true. In fact, I think most people that start in Emacs do so because they've heard that old experts use it, and know they will have to put some effort in to understand why.
> That's great and all, but people who are learning emacs for the first time don't know or care that it's one of the most successful text editors or that it's been around for 40 years. They care about being able to write code effectively.
I started using Emacs ~2008 and it's longevity has been a major factor in my decision, as I thought it would likely be usable for the next 30 years as well and help me to avoid changing environments every few years with each new hype.
I don't think nice color schemes are the point - although I do highly appreciate them.
I've tried Spacemacs and it's pretty nice. Using it in vi-mode, it provides multicursors that are far more advanced than in any other editor I know. Also it has a sidebar.
On the other hand for me Spacemacs is pretty buggy (macOS + Linux), I sometimes have to redo commands. Some important vim shortcuts are not implemented and the sidebar is also not always working as it should. Therefore I refrain from adding more plugins to the mix.
Experienced Emacs tend to not use the Spacemacs theme and are working with solid configurations. Maybe a rock-solid default configuration would work.
Yeah, unfortunately doom isn’t designed to be beginner friendly. I’m personally in two minds about customize. It is quite clunky and I think it’s too easy to have your customisations overwritten by customise or something else or to have them overwritten in confusing ways. But it also gives a non-lisp interface to a lot of customisation (manually setting up the data structures can be a big pain to get right without it).
I'd also say it's a good choice for beginners. Providing one way to configure things and explaining that reasonably well in tutorials and docs is fine.
The only downside of Doom Emacs for a beginner like me is the non-standard package manager: Just following some packages docs for configuring isn't enough, it's also required to figure out when to execute that config code.
It's easier this way for a beginner. Things are consistent; You put `(setq foo bar)` in your config. It's very intuitive. (I have also lost some settings to customize's bugs in Spacemacs.)
Then the solution is to just point people to some of the popular starter packs when emacs starts for the first few times. I think Doom is pretty rad by default.
> It is widely used for a staggering array of tasks.
Is it? What area are you in? In my hobbyist, college, and industry experience I've never seen anyone use emacs for anything. I have seen Vim (or at least vim bindings) a few times, but I only know of emacs from older unix discussions online.
Edit: Looking through stack overflow developer surveys, emacs use is in 16th place for editor popularity at ~4.5% usage, but has stayed close to that number for years.
Half my fifteen-person team at work (in a fast-growing mid-size fintech company in Chicago) uses Emacs, for editing/testing/running code in several languages, interacting with Web services, running various shells, calendar functions, document writing including UML diagrams and mathematics typesetting, and personal planning (Org Mode). To do this, we collectively probably use about 0.1% of the publicly available extension packages for Emacs on MELPA.
But the short summary is that most people use it for the various functions an IDE provides. The major difference between Emcs and other IDEs (VSCode, IntelliJ, ...) is that (a) it's often a little harder to get functionality that is provided out-of-the-box by another IDE, but (b) it's much easier (in some cases, infinitely easier) to implement workflows or functionality not already implemented by said IDE.
As an example, I often run snippets of code and want to insert the result directly beneath the code in question (similar to Jupyter in Python, but for any language, in plain text, directly in my editor). A trivial amount of Emacs Lisp gave me that with minimal effort.
If you like to have nearly absolute control of your editing experience, Emacs might be interesting to you. For most people starting out, who just want to get hacking on some code as quickly as possible, it is perhaps not the best fit.
What's really amazing is vscode just appearing out of nowhere (7% in 2016, 35% in 2018). Blindsiding everyone. Cross platform, excellent to good enough UI/UX (very much inspired by Sublime Text but free), easily extensible in a widely available (and widely taught) language. For better or for worse.
The huge advantage of VSC: plugins can use HTML to implement whatever UI they want, from a workflow tool, to a test tool, to a Git graph view to a debugger data structure visualizer. And all that in widely-known to tons of people HTML/CSS.
Never understood why other editors, like ST, didn't give more UI options (checkboxes, buttons, dropdowns, a canvas, etc) to plugin authors. Consider how clunky a lot of plugin interactions with limited UI widgets available to them are.
But even if other editors started giving more freedom to design your plugin with more widgets etc, they could never beat the freedom HTML/CSS gives.
The second huge advantage of VSC: Microsoft behind it updating it non-stop. TextMate stalled, ST seems abandoned for long stretches of time (and it's not like we "already solved code-editing, what more you want") because of lack of manpower, etc.
The third advantage of VSC: first-class support for plugins, with "package manager" and storage built-in: plugin discovery, install, uninstall, enable/disable, configure, are all a click away. ST has this too, but not as refined as VSC, but more like a tacked-on text-based experience.
Two more advantages of VSC:
- remote development tools (MS). Code in your laptop, run/debug in SSH/Docker/WSL environment.
- automatically saved/synced preferences. This came in in this release.
I'm not in favor of Electron apps over native. But VSC is really that good.
The last two are more of disadvantages; The remote setup eats a lot of memory from the remote machine, and needs an excellent internet connection, and can't integrate with local editing (You have to use two separate windows, and it's in general nowhere as neat as tramp). The saved prefs are synced without version control, which means you can't really count on them.
It is the only Electron app that I tolerate willingly, but hoping that eventually React Native team at Microsoft will manage to drive a transition, somehow.
I was an avid emacs user for almost a decade and it only 2 a week with VSCode for me to jump ship completely.
The issue I had with Emacs is that while could get it to do anything, often it took a lot of time. I would often end up spending an entire afternoon or Sunday tinkering with my config to get set up to develop in a new language. Whe I adopted VSCode it took about 20 minutes - install a plug in, set some config. I had a better setup for Elixir in a text editor I had never used before in minutes, after having spend hours achieving an inferior result in Emacs.
The reason for this basically comes down to abstraction levels in a couple of places.
Language support in VSCode is at the 'plugin' level whereas in emacs you usually have to assemble several pieces. Partly this is achievable because VSCode made their own life easy pushing the hard work of language support out using the language protocol. Its widespread adoption in a relatively short time is a great benefit to everyone (emacs included).
I get that, but VS code plugins are generally mediocre at best. If I want a “install plugin and it works” editor, I use IntelliJ, which does a better job at basically everything.
I'm curious as to which plugins you have used to have that impression. My plugin experience with VS Code has been generally great. Far better than any Jetbrains product I've used, I dare say.
It’s surprisingly easy to grind performance to a halt in VSCode using the extensions (even on a modern machine of course) much like using a browser with extensions (but worse).
That said the only reason I use VSCode instead of Vin is when I program in Typescript because the support is outstanding, always cutting edge, and super easy to set up. Code is ideal for frontend js programming in general with lower investment.
Similar to how awesome Emacs was for Clojure and Lisps in general.
But nothing will peel me away from (neo)Vim for generally everything else. I love how fast, portable, and perfectly customized I’ve made it over the years.
The difference with vim vs emacs vs VSCode is probably like the value with the community size and plug-in support. Just like programming languages become great through having great libraries and frameworks and tutorials etc, being popular has tons of value. After simply being good at all the foundational stuff.
> It’s surprisingly easy to grind performance to a halt in VSCode using the extensions (even on a modern machine of course) much like using a browser with extensions (but worse).
The same is true for emacs, or vim or any other extendable editor. Poor code behaves bad everywhere.
But the real surprise is, VS Code usual performance is equal or better than emacs even with an average setup which is still a tad more powerful than whatever emacs offers on a good setup.
A product doesn’t need to be excellent to be popular. Take for example McDonald’s or Burger King. You will not get excellence there. But you will consistently get a filling meal to a quite good price. Or take TV-series. They don’t need to be excellent either to get lots of viewers. They just need to be available and entertaining.
(I don’t mean this as a critique of VSCode. I have never used it.)
I mean, to each their own. Someone else using an editor I dislike doesn’t harm me in any way. But if someone told me that VS Code was “best in class” for anything other than a language I have never touched and have no knowledge of, I’d look at them like they’d just asserted that the sky is green.
well, the same can be said of Swiss martial cutlery...
To connect this a bit back to emacs, I think the big contribution VSC has made is to popularize the language-server concept, which decouples the UI from the automagical autocomplete and context-sensitive documentation we expect from IDEs.
Emacs's lsp-mode and (I'm told, not yet tried) eglot make it possible to use emacs to productively write java, something I won't attempt without tooling support.
The LSP interface, like slime, enables a whole class of interaction, rather than re-implementing the language support for each languge, like in days of yore.
That truly is a modern coding practice, brought to emacs.
As avid Electron hater and someone that found refuge in XEmacs, back when IDEs and UNIX did not mix, it is a matter of defaults and not everyone likes ELisp.
Sure, but it’s not like the choice is between Emacs and VS Code alone. I for one find IntelliJ to be far superior to VS Code for the languages I use. Especially since search and autocomplete actually work, which it doesn’t do in VS Code.
VSCode has the power of free beer, and most major plugins are done by Microsoft, Red-Hat, Google and friends, while most InteliJ goodies are available online on the commercial license.
I wonder how many devs are motivated by that. All of the ones I know are already using OSX, so standing on principle for just the IDE would be incoherent.
Hardly seen outside first world countries, and even on Europe it isn't easily spot outside the rich EU countries.
I did a couple of consulting gigs where the only iMac available for the Dev teams was used in turns for iOS deployments, for applications done in cross platform frameworks, where 90% of development time was spent in Ubuntu and Windows based computers.
VS Code is pretty much the proof that a modern Interface and beginner-friendly customization is the secret of success even for editors. Of course only additional to a solid foundation in terms of ability.
> emacs use is in 16th place for editor popularity at ~4.5% usage, but has stayed close to that number for years.
It is possible that "Stack Overflow surveys" select for programmers who tend not to use Emacs. For example, I use Emacs regularly and know what Stack Overflow is, but have never taken one of these surveys.
I'm not even sure how they survey developers. Ask on some crufty mailing list and you probably will get a completely different distribution from the one they showed.
Emacs users are probably more likely to unsubscribe to newsletters that they did not sign up for :)
(On a side rant, I really dislike how a lot of websites have normalized “create an account on a website” to mean “Sign up for receiving a plethora of emails about everything the website and its creators are up to these days”)
>On a side rant, I really dislike how a lot of websites have normalized “create an account on a website” to mean “Sign up for receiving a plethora of emails about everything the website and its creators are up to these days”
Hear, hear. If I get an email from a company whose newsletter I didn't sign up for, I immediately unsubscribe... but I really shouldn't have to.
One of the greatest parts about owning my own domain is using different email addresses for these random websites that want to blast me with newsletters. That way, I can just redirect spambotscrapinghn@snazz.xyz to the trash if they sold my email address or I start getting spam to that address.
You can do the same thing in Gmail with the +, but some websites filter those out or don't allow them.
What websites have you had issues with? I started doing the same thing with my own domain about a year ago, but I haven’t see any unsolicited emails to any of the addresses yet.
I was expecting you to say "I immediately mark it as spam". Do it, treat unsolicited newsletters like the spam they are. If enough people do this, it creates significant problems for the authors of such email.
Meanwhile, I’m always amazed how, on HN threads about Emacs, people talk about preferring the Vi family of editors. When I installed Linux on my computer two decades ago and had to learn *nix, my own (totally subjective) impression was that the Vi family was regarded as clunky and half-obsolete, about as much of a pain as editing in ed. As I began to contribute to the Free Software community, most of the other people I interacted with seemed to use Emacs. So, to find out that Vi is still used and loved in 2020 has been a shock.
When I entered a technical University in Spain, all the masters(teachers that have done incredible things on their lives) used either Vim or Emacs.
Most "normal" people just used other "more visual" editors.
As I learned from the masters I started using more and more both vim for unix tasks and programming and emacs for lisp. Now I use 65%vim, 30% emacs, 5% other editors.
Both of those editors are extremely powerful. But you need to know how to use them. It is not painful for the master to use them, in fact it is automatic and instantaneous and faster than any other editor, a thought becomes an action without conscious intervention, like you thing in playing Do minor in an instrument and your fingers do it automatically, you want to erase a line or replace a word, you think on it, is done.
They are like musical instruments. You could have the best piano or violin in the world, if a mediocre player plays them, you get bad sound.
Most people would be better served with a simple electronic piano or a tablet with lights that point to the next notes of the song, and auto correct them when they play a bad note.
Your reference to musical instruments resonates with me (I play piano) and the fact that emacs call they keyboard bindings "chords" further complements that view.
I guess the issue that is being handled here thought is that, just like the piano, the road for those actions to become unconscious is a long painful one.
When I started using Golang for work the first thing that I did was buy GoLand from jetbrains. It just works, and I'm paid for "playing piano", not for "learning how to play piano"
I wish I was able to use emacs professionally but until I'm able to dedicate (usually unpaid) time to learn it, it's just easier to use something else
It's really not that painful. In college I spent two weeks forcing myself to use emacs for everything. I printed out a reference card and unplugged my mouse to prevent cheating. It was not a productive two weeks, but afterwards I was proficient in emacs editing and have been ever since. (Of course true emacs mastery goes much deeper, but it really doesn't take that long to become proficient.)
A broke college student with nothing to lose but time and a professional programmer have entirely two different definitions of "painful". A broke college student will spend two weeks learning emacs to avoid paying for a $100 IDE. A professional developer will happily pay for a $100 IDE if it saves him two weeks of time.
It's an investment and the payback is considerable. I can start up emacs in any environment and it works the same. I could go back 20 years and use emacs without trouble.
Also I can move around in emacs and do stuff with macros that has saved me a lot of time. And emacs rarely has problems, unlike visual studio, which crashes occasionally and is permanently sending my dual-core to 100% of both.
Emacs refactoring, heh, not so good... So I use both, do main editing in emacs.
But you're not going to go back 20 years. No one's going to come along with a time machine and send you back to the year 2000. And, unlike vi, emacs isn't part of the POSIX standard, so your production servers aren't going to have emacs preinstalled. If you're a new programmer, with zero experience, why would you bother learning a program that is going to make you less productive than your peers and isn't going to give you any advantages when you're debugging in production? What exactly is the payoff to this "investment"?
Proficiency? Proficiency in what? Proficiency in learning a completely irrelevant language to spend two months getting up to the same level everyone else gets to in two weeks?
> in fact it is automatic and instantaneous and faster than any other editor
Really? I've always found emacs to be on the slower side of things (not nearly as bad as jetbrains / visual studio, of course) and many keyboard commands to be unnecessarily clunky. I don't know how many times I've given emacs a go, and yet I can't seem to get nearly as proficient as I am with VSCode (and sublimetext before that).
I know part of it is that I don't typically work in languages where having a live REPL up is terribly useful, so emacs support tends to be a bit... second class.
I think my biggest gripe is that there are actually two mountains to climb. First, you have to become proficient with emacs- the chords and so forth. Then you have to find the magical combination of plugins that work together on your operating system with the magical configuration that brings emacs up to par with things that I consider to be table stakes for a good development experience. Doom emacs probably got me the closest there, I think, but struggling to become moderately productive when I already have a tool with which I am extremely productive seems entirely pointless.
I think the thing about Vi and Vim that has the most value in 2020 is not the software itself, but rather the keyboard-centric composable modal editing system that they popularized.
Some of the growth that Emacs has enjoyed over the past several years is from folks who want the Vim style modal editing in an editor as customizable and extensible as Emacs. Emacs "distributions" such as Doom and Spacemacs cater to these folks.
I came to vim (years ago now) because I was experiencing RSI from all of the chorded keyboard shortcuts I was using in Coda. Emacs doesn't help with that, but vim does (if you `map ; :`).
Any editor feels clunky for the first week of using it, Vim and Emacs most of all. Nobody wastes the headspace in staying current on multiple editors. So I don't know that you'll ever see an objective comparison of the two. But they're both solid ways to write code, it just takes way too long to get either one dialed in to do the things we expect modern editors to do out of the box, like code completion.
I switched from emacs to vim for the same reason. I was doing a lot of typing, and my left hand started aching when I was stretching my fingers and eventually it just started aching all the time. So I thought, why not try vim, which I had used many decades before.
Things were very slow for a few days, and there was a lot of swearing, as I got weird results from hitting a wrong key. But after about a week I was able to get along adequately, and after another one, I was at the point where I was making choices for optimal methods without really thinking about whether typing 2w would be better than holding j for a while.
I think the key was that I made the switch during a vacation, when my workload was lower and I would not be so frustrated by learning enough that I could select between methods.
Learning either vim or emacs in a rush is not good because you are likely to become habitualized on a small subset of methods, and will be blocked from learning other methods that will increase your productivity some day.
I know I fell into it because I originally learnt UNIX on shitty XENIX servers which were basically AT&T SVR4 on x86. The internet and Linux weren't around then.
Later on I had to work with a number of different versions of different UNIX platforms on a daily basis (Tru64, Solaris, HP-UX, AIX) as well as multiple varieties of Linux, and vi was a common denominator on all of them.
I've personally known 2 Emacs users in my ~15 years in the industry. I've worked in Europe for various startups and a bunch of corporations. Both of them used it as a sort of hobby/side editor, their main money maker was an IDE (VS, IntelliJ).
I've probably worked with 500 developers, if not more.
My personal impression is that Emacs is like the Yeti of programming editors. Everybody has heard about it, few claim to have seen it and even fewer still can claim to have proof of the sighting :-)
I already wrote this to another comment, but quoting myself:
> Is this a USA vs the rest thing? I've worked in many startups in the US and almost everyone uses emacs. Last few years, VSCode has been getting popular though. I had a similar experience when I was a student in UC Berkeley, although it seems like there were more vim users in school than in industry. Anyway, pretty much all my current coworkers use Emacs and I work in Boston, MA.
> Personally: I cannot imagine programming without emacs, to me programming is so strongly associated with emacs...
> Of course, I also understand that it's all personal preference.
I don't know if there is a way to prove that I'm lying. :)
I've worked in California all my life and have worked in the following industries: medical devices, scientific devices, blockchain, and plasma physics research. I am the only person I've seen use emacs. Almost every developer I've worked with either used VS Code, Visual Studio, or uVision. Everyone else used Sublime Text, Eclipse or a JetBrains IDE.
I haven't even used emacs in years so I don't even know anyone that uses it; I stick almost exclusively to Vim (and for 8 months this was my only "IDE"), PyCharm, and WebStorm.
I mean, just go on YouTube and start clicking around in random presentations at programmer conferences.
Unless it’s an emacs related conference you will rarely see emacs being used as an editor. You will see a few VIM users sprinkled around. But if it’s a recent conference the vast majority are gonna be VSCode users.
Huge skew depending on what platforms you like to work on. Java or Windows people are significantly less likely to use trad Unix tools. Backend or Linux people, it's 30/30/* in my experience between vim/Emacs/everything else -- this was certainly the case at Google when I was there.
If you're happy with vim, stick with it. In general, when it comes to editors, you're better off trying to get really good at the editors you already know than being mediocre at using a bunch of different editors.
Here's what I do in emacs that makes me like it better than vim. If you want to do things like this, you should consider Emacs. If not, you are likely better served by Vim.
- I write software with unit tests. I have a custom method bound to Shift-F5 that computes the test file associated with the current code file, and switches to the buffer.
- I have a similar method bound to F5 that runs the tests for the current file (code file or test file). Ctrl-F5 to run the previous test again even if you're in a different buffer.
- These are configured for multiple programming languages, testrunners, and different conventions within specific programming languages, in different parts of the codebase.
- Test output goes to a first-class buffer, like any other file I'm working on. If I want to do something like `git blame` the file I'm working in, it's also a first-class buffer. Want to run a shell? `tail -f` some logs? All in first-class buffers.
- Why does it matter that things end up in first class buffers? Well, there's lots of random goodies like `meta-x json-pretty-print-region`, so if your execution dumps a blob of unformatted JSON or whatever, you can manipulate it readily. (Tab complete is available on these commands.)
- Autoformat your code automatically with a save hook. Autoformat it on your own schedule by calling something like `m-x blacken-buffer`. I don't think vi does as good a job of manipulating the contents of your file with internal and external programs.
Vim can do all of the above pretty easily. In fact, I have a mapping for json pretty-printing, filtering it with jq; mapping for autoformatting with black or other formatter depending on file type; a plug-in for undo history tree. I don't have configuration for running tests the way you do, but I know a guy who does something very similar in vim.
I don't think the things you describe are the differentiators for the Great Editors. For me it's more their phylosophies that make them stand apart: despite the wide usage, vimscript is far more clunky, narrow-scoped and less powerful than elisp. Which means that stitching together something complex is hard and awkward in vim. Emacs is far more suited for complex processing due it's nature of a lisp machine. The chords are awkward though. So, "emacs is a good OS, but it lacks a good text editor".
> I don't have configuration for running tests the way you do, but I know a guy who does something very similar in vim.
I would love to see that: everyone I know who uses Vim ends up typing out test names in a separate terminal, or running some sort of a shell-out command that suspends editing of the current file until it is complete, and then hides its output.
I second gnulinux’s comment, that is amazing. I would estimate that over 1/3 of my colleagues over the years used Emacs at least once a day and for many it is their main driver.
It seems like I spend a fair amount of time mosh/tmux to remote servers and I like copying over my Emacs configuration, be up and running. Same for users of vi or vim.
VSCode has good remote server development support also, so there are great options to keep most people happy.
Depends on who you know. Among my friends who went to MIT, a good number use emacs. It’s really, really nice to be able to use the same editor everywhere, regardless of whether you’re using your local machine or ssh’d into a VM or server. Also, knowing that it’s not likely to be deprecated in the next couple of decades.
That is very fair question. In my experience of html, css, js/ts, C#, VB, java, php, c/c++ and python I have never seen any emacs users in 20 years. I think it is really a language and region cut going maybe back to the universities supporting lisp or something else
Maybe it’s a region thing. Back when I did Python it was fairly popular, but VS Code appears to have largely taken over in that language, much to me continual confusion.
Most of the other languages you listed have extremely poor Emacs integration, both for cultural reasons (C# devs tended to be on Windows), and because some of those languages are so dominated by other IDEs that nobody bothered to write a good emacs extension. Java is a great example of this; the IntelliJ experience in Java is just so good, nobody managed to come anywhere close in Emacs, which created a self reinforcing cycle.
Since you mention IntelliJ, is it possible that the corporations you have worked in have been heavy on Java?
JDEE (http://jdee.sourceforge.net/) exists, but even I give up on Emacs when I want to write a lot of Java (and I use Emacs for literally everything else, including JS).
JS development in IntelliJ/WebStorm is an amazing experience. The refactoring features alone make it easy to write code without worrying about details like "where does the file go" or "what should I name this". You can get the code working and rename / move code with a single click later on, knowing the refactor will propagate through the app.
The intellisense is amazing too. Start typing a method name and you see arguments with type annotations. it's overkill for scripting, but working on tangled legacy code it's very helpful.
I wouldn’t write Java in an editor that wasn’t hosted in the JVM. The advantages are simply too great. On the other hand that’s a very Lispy attitude so Emacs still influences me. And Eclipse at least has tolerable Emacs style bindings available. Still it sucks how much more of a PITA it is to create an Eclipse plug-in than to just write a page or two of elisp.
Same here. 20 years, Europe, corporate and open source projects, zero emacs users. Seen vim, notepad++, sublime, uedit, atom and vscode. And all types of fat ides
I use Emacs for writing plain text because of Alt-q, and for tiny snippets. For coding I use real IDEs (JetBrains / Visual Studio) and can't be arsed to use a dumb editor, plus trying to configure to do "the right thing" w.r.t. to code style and indentation across a couple language is very annoying.
Is this a USA vs the rest thing? I've worked in many startups in the US and almost everyone uses emacs. Last few years, VSCode has been getting popular though. I had a similar experience when I was a student in UC Berkeley, although it seems like there were more vim users in school than in industry. Anyway, pretty much all my current coworkers use Emacs and I work in Boston, MA.
Personally: I cannot imagine programming without emacs, to me programming is so strongly associated with emacs...
Of course, I also understand that it's all personal preference.
This is a "your tiny bubble vs. everyone else" thing. I'm a professional programmer in the US, and, even when I was working in a Clojure shop, I was the only emacs user. Think about that for a second: even working at a company where every dev is paid to write Lisp, I was the only one who bothered to set up emacs. The other developers were using the Clojure plugin for IntelliJ or the Calva plugin for Visual Studio Code.
And, to be honest, I can't exactly blame them. I tried setting up Calva the other day, just to experiment, and its out-of-the-box experience was far better than emacs'. It was literally just a matter of installing the extension and loading a Clojure project (I was using Leiningen for my project definition, but Calva supports others as well). It brought up a REPL, it started doing autocomplete, and you could even hover over symbols to view their documentation. And none of this required any kind of manual configuration on the part of the user.
At this point, I honestly can't really recommend emacs to any developer who doesn't already know how to use emacs. If you want to start programming, just download VSCode and get the plugins for your favorite language.
From your username and Boston's proximity to MIT and FSF, it's possible that your experience isn't totally representative. :)
Mine isn't either and I find it hard to imagine owning a computer (or using git beyond the very basic operations) without having access to emacs, but it does seem likely that coworkers won't have completely independent text editor preferences. I would expect to see more VS and VSCode in the Redmond, WA area, even at places that aren't Microsoft.
> I've worked in many startups in the US and almost everyone uses emacs.
Others claim the opposite. Maybe the contradiction is explained by the hiring culture. Startups with emacs users hire more emacs users. Not that they would make emacs usage an explicit criterion or even ask such interview question. But probably there are some properties over-represented in 4% (or whatever the figure is) of programmers that are emacs users.
Disclaimer: Part-time emacs user since 1986 or so, full-time emacs user since 1989. Should spend some time to learn the newer features / customize it in a more compatible way with the rest of my software. I am lazy to make "another" editor as Stallman puts it even if I like Lisp hacking occasionally, but I would happily switch to a modernized configuration if it were available upstream.
It has definitely been this way _as far back as I can remember_ (at least the last two decades).
There have always been popular tools. Most of them haven't stuck around though.
Emacs has.
I wouldn't recommend using it right away though. Instead, I'd recommended accumulating some pain by using other popular editor-like,workflow-like,manipulation-like tools, because that might be the only way to appreciate what Emacs brings to the table.
(though I have to acknowledge VSCode's achievement, gaining massive adoption in what has always been a fragmented space)
In my uni, many professors used Emacs when demonstrating. For example, one course [0] used the Agda language [1] as a proof assistant. Afaik, the only good interactive Agda interface is the Emacs Agda mode [2]. Maybe you just live in a region of the world that happens to have a weak culture of using Emacs?
I use emacs for everything. I'm a hobbyist and computer science major (sophomore, undergraduate). Hell, I use emacs to edit the markdown that gets rendered to a predefined Latex template for my philosophy classes!
org-mode and magit seem to bring in a lot of emacs users, even if they're only using one of those two things. If I stopped using emacs for code tomorrow, I'd still use org-mode and magit and still encourage others to do so as well, even if I also pushed a different editor or IDE for writing code.
I've worked with many programmers who use Vim, although I've personally never grokked it.
I've used Emacs for years for editing/programming, running shells and reading news/email.
I've attended two universities in the UK and it was used by default for some of their programming/computational courses; this was in different departments (Physics and CS), a decade apart.
Emacs has been used to build user interfaces (e.g. ProofGeneral, which was the de facto interface for theorem provers like Coq and Isabelle for many years).
Some programming languages de-facto assume they're being written via their Emacs mode (notable Agda; similar to how some JVM languages assume they're being written in Eclipse or IntelliJ).
Years ago I inherited an academic research project which happened to be written entirely in Emacs Lisp.
I think it hugely depends on the programming languages one uses (or used to use), as well as personal history. For example basically everyone learning lisp was, for a long time, encouraged to use emacs (I think this is still the case for Common Lisp but I’m not sure about other varieties). This makes for a pretty unpleasant lisp learning curve as most people are not already familiar with emacs. Other functional languages in the ML family may not be very similar to lisp in many important ways but because their lineage went back to lisp people and environments, emacs ended up usually being the editor with the best support, though this is less the case these days.
If one looks at computer history there seem to be several versions of a cycle that looks like “crap underpowered computer slowly gets more features and better performance only to become outnumbered by a smaller slower cheaper computer.” Depending on where one fell in that cycle, emacs may not have been an option (eg if you were starting programming on dos or an early windows you likely wouldn’t be using emacs. If you were starting at the same time using a Unix workstation, emacs might be a reasonable or recommended choice).
During the early naughties you were probably using windows and not exposed to emacs unless you worked on Unix/Linux based web backends.
You're going way back in time there though. I started like the other kids in my generation with BASIC on 8bit home computers, but my first paying programming job (early nineties on a shared Unix workstation which crashed about once a day, much more reliable than the Windows PCs of that era), I was given the vi cheat sheet. At first I thought that was worse than CP/M, but it did grew on me quickly. At home I used Emacs on a PC with 8MiB RAM (and it wasn't constantly swapping). Emacs was perfectly usable there, but when using a 9600baud serial terminal, vi was snappier.
I've used emacs ever since college. I've tried a bunch of IDEs, VSCode, Sublime, Atom, even vim. They just never felt as comfortable as emacs in the terminal.
I'm probably in the minority since, despite a decade-plus of use, I'm by no means a power user. I use a little bit of org-mode and babel here and there. I can hack around in elisp if I want to tweak a mode. But that's about it. To be honest, I don't even compile code or navigate the directory tree from inside emacs.
That being said, two reasons I don't think I'll ever switch. One, the key bindings and commands just feel more elegant. Don't know if that's because they're locked into my muscle memory, or they're genuinely better. Two is that I live in the terminal. IDEs are great, but I much prefer just piping find to grep to sed or similar bash-fu, when I need to do something fancy.
Same feeling, especially with the number of Org users that are not programmers, but just writers.
There has been a time for me, when I used vim for programming and Emacs with Org Mode for structured texts, like essays and articles, so I can imagine there being a lot of people outside of the CS and dev bubble enjoying their Org Mode and not being counted by any survey.
Heavily language dependent. I used nothing but Emacs until I switched over to Java, where IntelliJ is king. The level of Emacs usage I’ve seen depended a lot on what language was being used, it seemed much more popular for Python users than Ruby, for example.
The hypothesis that Emacs is used for many things is consistent with the hypothesis that Emacs usage is rare. This is because many humans have existed over the years, so a staggering array of tasks can be addressed in even a small fraction of those person-years.
> When I see a highly successful 40+ year old piece of software, my first instinct isn’t to ask what the people behind it can learn from me but what I can learn from them.
This is how incumbents die: when the fact that something has existed for a long time is taken as proof of it being at no risk of disappearing.
I used to work for a company that has been around for roughly 150 years. And it is precisely the attitude that "we've been around for 150 years" that made it blind to the fact that in the last 15 years, it has become a little bit less relevant every year because disruptors slowly eats away its market. In one sector the company would boast 3% growth year over year - while glossing over the fact that the sector had a growth of several hundred percent per year. You can have growth and at the same time lose market share at an astonishing rate.
This is kind of what happened to Emacs. There has been an astonishing growth in the number of developers over the past decades. Which means the "market" for editors and IDEs has exploded. And while more people may be using Emacs today than ever before, I would hazard a guess that the market share has gone down.
I agree that age is an issue since design decisions were made before standards were agreed upon, and it is going to be very disruptive to change those design decisions. Changing keybindings is certainly going to cause pain, but even remedying terminology is problematic (e.g. window vs. frame). That's likely why cosmetic issues were popping up as potential solutions.
I agree that those cosmetic changes won't modernize Emacs in a meaningful way since it is a very low bar. I also think the article is correct in pointing out that discoverability needs to be addressed. Contrast Emacs and VS Code in terms of extensions. Both editors are intended to be extended. VS Code does a good job of highlighting extensions, while the Emacs extension manager is buried. Likewise, Org seems to be rather popular yet very people will discover it independently since the user interface isn't designed for that.
That said, some of the discussion about discoverability was disheartening. Telling people about features isn't really sufficient. They need to be exposed to it while they are working with the program, and that exposure has to be in a non-disruptive way. Tutorials, video or otherwise, aren't going to help because of that. There are plenty of Emacs tutorials online anyhow.
If the LWN article is an accurate reflection of the discussions, I think that Emacs developers have to put a lot more thought into how to progress.
I feel old when I see ”modern Emacs” and think “Oh, maybe they are finally either finishing off Guile Emacs, or porting the extension language to Common Lisp”.
I guess I agree that ibuffer should be part of the standard distribution. Less sure about undo-tree, but could be an option if the authors released it under appropriate licenses (I understand that contributing code to Emacs is somewhat cumbersome; although if I were smart enough to do so, I would jump through the hoops in a heartbeart).
It's over 40 years old but it has fewer and fewer users younger than that. VS code is rapidly taking over it's niche and without modernization, of many kinds, emacs will die out in a generation.
I have used emacs since I was an undergrad, 25+ years ago and I have no plans to switch. That does not stop me from recognizing the fact that VS Code does almost everything that emacs does, often better, has orders of magnitude more users, is much more approachable and is being improved at a much faster rate. As they say, "this time its different".
This kind of ties back in to the point of the article.
For people who have used $EDITOR for 20+ years there's little incentive to change to something else, but if you want to bring in fresh eyes to your project so that there'll be enough people around in another 20 years to maintain the whole thing it behoves you to think about attracting those people.
Sane defaults and being more approachable is a good way to do that.
That is the splash page that hasn't changed much since 2000. Reading the helpfully highlighted first menu entry do you think that Emacs has a tutorial?
Users who can't even be bothered to read the text in front of them are not an asset to a project that doesn't charge them, they are a liability since they force the project in stupid directions. The death of firefox is a perfect example.
The thing that Emacs should focus on the future is true concurrency. Nice to haves would be a non-gtk gui, adding scheme scripting support and releasing a space cadet mechanical keyboard.
I don't follow this stuff closely, but I do have it in my RSS reader.
Here's someone recreating the Space Cadet keyboard key caps -- i.e. the plastic covers for the keys, not the actual keyboard. This is a more modern profile (key shape), rectangular/cylindrical similar to modern keyboards rather than the spherical top of the key like in the 1970s and 1980s.
It might give you an idea how expensive a custom keyboard would be.
I've been using Emacs for an entire 1 year and I have to say - I only like OrgMode. I've barely tried out Magit, so maybe that's another killer feature. But for programming, I think that Emacs is too steep a hill to climb when VSCode and JetBrains' IDEs offer so much out of the box or just a few clicks/commands away. In Emacs, you can can, in theory, do anything you like. And it is so impressive when you customize it to behave in a certain way. It's also more open for tweaking than any other editor. 'describe-function' and 'describe-key' are super cool, for example. But VSCode is just more practical. Instead of writing some Elisp (which is an incredibly awkward language) to customize your IDE, you can just go to the extensions screen and very likely find and download an extension that does what you want. Maybe not exactly. Maybe you could make Emacs behave much more precisely, according to your preferences. But you might spend hours, if not days, depending on your level of expertise. Meanwhile, with VSCode, you essentially bypass all that.
You are totally right. Being an emacs user for 10 years, I suggest vscode when people ask what editor to choose.
While preconfigured Spacemacs, Doom and others are doing a good job in turning emacs into OOB editor, they still require some tinkering with lisp, while in vscode you just install plugins and you are done.
Have you tried preconfigured Emacs distributions, like Doom or Spacemacs? You just open your init.el file and uncomment packages you want to enable with pretty good defaults. They have package managers preinstalled too, like straight.el. Also, every package has easy to paste initialization snippet
It helps to have a lot of very visible brackets when people sign up, it scares away the majority who won't cut it.
Emacs is in that unfortunate position that you can learn the shortcuts and 'use' it for months before you even see your first bracket and end up thinking the brackets are the problem, not you.
The number of times I've heard people demand the scripting language change to python...
For comparison of numbers and growth rate: VS Code was new in April 2015, had a claimed 2.6 Million active monthly users in Nov 2017[1], became the most popular editor in StackOverflow's user survey in 2018[2] with 34% of respondants and again in 2019 with 50% of respondants, to a claimed 11 million users in 2020[3]. Its codebase has been forked 16,000 times[4].
In 5 years, VS Code has gained more users than the population of Switzerland, than the population of London, than Uber has drivers. I'm not suggesting Emacs ought to chase maximum popularity, but if there was any feeling that "the editor / IDE market was saturated" or "there was no demand for editors", that doesn't seem accurate.
I think adopting cua-mode as the default would go a long way towards reducing the initial friction for new users.
Most of the time when I try to get people to adopt emacs, they abandon it because it feels like a huge task to relearn basic text manipulation. They never get to actually see what makes emacs good because they don't feel compelled to get past the initial bump.
Have you tried with a init.el with cua-mode to see how people adopt it? My intuition is incentivizing on org-mode or magit has higher chance of adoption than cua-mode. After all an alternative free editor(VSCode/notepad) is probably good enough for their current usage.
But here's the question: If Emacs defaulted to CUA, how many of those people would get to see Emacs's goodness? CUA alone doesn't get you there. To do most of the things that make Emacs stand out involves a fair amount of learning (and possibly customizing).
You have to put in some amount of effort before you get its benefits. While I certainly don't mind making simple things easier (e.g. CUA mode), I also see that doing so will not help new users much beyond doing very basic editing.[1] There are a fair number of stairs to climb to get to the point of being useful, and superficial stuff like CUA, etc simply eliminate perhaps 5% of the steps. Don't expect this change to make a big difference in retention.
As a corollary: If someone is not willing to learn how to enable CUA mode in the config file, then it is highly unlikely they will ever learn to use the features that make Emacs salient.
[1] I know, because my first decade of Emacs use was like this. I got past CUA mode, but otherwise used it for very basic editing. I always installed an IDE to do "real" work. It's only after one of my favorite IDEs died did I decide I really should just learn to use Emacs properly, and invested a week's worth of effort to be proficient in it. That week made all the difference.
> If someone is not willing to learn how to enable CUA mode in the config file, then it is highly unlikely they will ever learn to use the features that make Emacs salient.
I think that’s uncharitable. For a newbie low on confidence it’s often death by a thousand (paper) cuts: CUA mode, Surprising undo model, How to download packages, How do I enable fringes/margins, Windows-vs-frames, etc.
Each small change has a cognitive tax, and allowing users to feel psychologically comfortable and add tweaks slowly will make the learning curve much gentler.
I wouldn’t be surprised if the strongest indicator of whether someone sticks with Emacs is whether they have access to an Emacs expert with whom, or a community where, they feel comfortable being a newbie.
> I wouldn’t be surprised if the strongest indicator of whether someone sticks with Emacs is whether they have access to an Emacs expert
A lot of benefits of Emacs you get are when you realize you are operating a lisp VM. Enabling all the same things that other editors do in the same way will not suddenly make them choose Emacs. Someone needs to nudge them towards the good parts of emacs/show a powerful application that will make them use it.
I tend to get surprised by this complaint - especially in the article where undo-tree was recommended as an alternative.
Both the Emacs undo and undo-tree are "surprising" models in that very few standard editors support anything beyond the most basics. Personally, I've not had trouble with Emacs's undo (beyond it not visualizing it). Switching to undo-tree may be OK, but it's still surprising. Switching to the standard one in most editors is a pretty serious regression.
> How to download packages
Once I properly learned Emacs, I did not have a need to do this for the first few years. I'm not referring to decades ago, but the 2010's. While I agree that a convenient way to download things from MELPA would be nice, I hardly see not having it as a barrier. Most people new to, say, Visual Studio don't start with "How do I download plugins". And once you know some of Emacs basics, package downloading is but 2-3 lines in the config file and a keybinding that presents you a menu.
> How do I enable fringes/margins
Again, I don't see this as a beginner feature. I don't know how to do this, and I've never wondered about it - both as a beginner and as an advanced user. I've use Visual Studio quite a bit and never tried to enable/disable them there either. I don't think this is something a typical beginner would deal with.
> Windows-vs-frames
What is the issue beyond terminology? It wouldn't bother me if we rename these. I don't see a great enhancement, though.
> Each small change has a cognitive tax, and allowing users to feel psychologically comfortable and add tweaks slowly will make the learning curve much gentler.
Although I personally don't recommend it, but have you heard of Customize in Emacs? It used to be (and may still be) the recommended way to change config options. It has help on various options, and is an interface - not "edit config file with Elisp commands". Many users say it really helped them and certainly flattened the learning curve.
> I wouldn’t be surprised if the strongest indicator of whether someone sticks with Emacs is whether they have access to an Emacs expert with whom, or a community where, they feel comfortable being a newbie.
I did not have access to an expert. I simply read a book on it[1], and the rest was from occasional Google searches. In those days there really wasn't that much friendly info online, but it was enough to maintain the momentum. There is a ton more stuff these days to help beginners. Not to mention Youtube videos.
(BTW, as a reference point, I was a power Emacs user for almost a decade before I learned enough Emacs Lisp to write a simple loop - too many people have the misconception that one needs to know elisp to use Emacs well).
As someone commented on HN in an earlier submission: Who becomes a power user of anything without reading manuals? That it's not straightforward to do simple text editing in Emacs is a fair criticism[2], but also a bit of a shallow one. There are plenty of friendly text editors for simple text editing. Let people use them! The value proposition of Emacs is in its powerful capabilities, not basic text editing. It's a bit like complaining that Ferraris are a pain to learn to use when all you will do with it is grocery shopping. Just use a regular car!
[1] This was the norm in the pre-Internet days (80's and 90's), BTW. Even in the 00's when interfaces were nicer, the people I knew who were power Visual Studio users became so by reading books or online manuals - not by random discovery or random Internet pages.
[2] It's ironic that I write this, given that the only reason I began using Emacs is that the other option people led me to (vi) was even harder to do basic text editing. At least with Emacs, I could type and it behaved like most editors I'd been accustomed to in DOS. With vi I was immediately confronted with command/insert dichotomy, not being able to edit prior to the insertion point, etc.
It's also amusing that people complain about Emacs not being like "normal" editors, and folks invoke Stack Overflow polls to indicate its lack of popularity, and yet vim is used by a quarter of SO users and is ranked 5th. vim is also beginner hostile, so the beginner hostility really isn't the reason for Emacs's low usage.
I don’t wish to do a point-by-point rebuttal as you’re entitled to your view — just that it misses the perspective of a large fraction users. As for me, I’m fairly happy using Emacs Doom.
> While I agree that a convenient way to download things from MELPA would be nice, I hardly see not having it as a barrier. Most people new to, say, Visual Studio don't start with "How do I download plugins".
I think this statement is untethered from reality, and matches approximately zero people I know. Almost everyone using a text editor is using it for purposes which would definitely be helped by task-specific enhancements (plugins which are typically much easier to get in other editors/IDEs)
> I did not have access to an expert. I simply read a book on it [...] given that the only reason I began using Emacs is that the other option people led me to (vi) was even harder to do basic text editing.
Yes, and the fact of the matter is that today people have many editor options which are very powerful and also have a much friendlier learning curve.
> I think this statement is untethered from reality, and matches approximately zero people I know.
Note that I'm referring to Visual Studio, not VS Code.
In my last job, we didn't use any plugins with Visual Studio for a bunch of years before one developer convinced the rest to use Resharper.
> Almost everyone using a text editor is using it for purposes which would definitely be helped by task-specific enhancements (plugins which are typically much easier to get in other editors/IDEs)
I find this statement untethered from reality. I think this gets to the crux of much of this discussion. There seems to be an implicit assumption that Emacs exist for writing code (hence the comparisons with VS Code, etc).
I think if you poll most Emacs users, while programming will definitely have more weight, a lot of people use Emacs for all kinds of things unrelated to programming: TODO management, document authoring, writing emails, etc. Most of my Emacs usage in my first job was simply editing text files, not programming. This is in line with most non-SW engineering jobs: They need text editors, but not plugins. Over 95% of my home usage is non-programming related.
So when you imply almost everyone using a text editor is using it for purposes where they will want to look for plugins, that's simply far from the truth. Until recently, most people who used text editors used Notepad (the default Windows one), and I've never managed to convince a Notepad user to use anything more powerful. Nice plugins would not sway them.
While Emacs is heavily used by some programmers, I do not think it is the aim of Emacs. It is a general purpose text editor, and a platform for writing text oriented apps.
One small comment, many users do get plugins almost immediately.
If you load a (for example) Java file, a little popup appears saying "Hey, do you want me to download the default Java plugin". Now I can imagine Emacs would find it incredibly hard to pick a "default" plugin to offer users, but it is super helpful to get started.
> Although I personally don't recommend it, but have you heard of Customize in Emacs?
I have, I've tried it, and it's terrible compared to virtually any other editor's equivalent for editing preferences/settings. It's super hard to navigate and search, it's difficult to figure out the terminology if you don't already know it, it's unclear how various settings affect one another, and IIRC it can actually make changes to your configuration file that conflict with editing it in any other way. To be fair, I am not a regular Emacs user, but getting sucked into the insanely frustrating tar pit of Customize made Emacs seem far more inscrutable to me for years.
If I could suggest just one change to make Emacs feel more "modern," it would be to entirely redo the Customize section to make it behave more like VS Code's preference system: one single page with collapsible headings, clear descriptions, and perhaps a super-top-level "behavior" control that makes batch changes to make Emacs more comfortable for users coming from different editors (e.g., choosing between a Canonical Emacs mode, Vim mode, or CUA mode). It doesn't have to try to cover every possible setting -- just hit the top several dozen and then say "for everything else, there's Lisp".
> Vim is also beginner hostile, so the beginner hostility really isn't the reason for Emacs's low usage.
This strikes me as half-correct, as someone who's made serious attempts with both of these editors. They're both difficult for beginners to get used to, but once you get over the initial learning hump, Vim was always much easier for me to tweak and configure. That may sound nuts, but editing .vimrc feels like editing an INI file, and at least in my experience, Vim's plugins are much better behaved when it comes to not stomping on one another. Every attempt I've made at getting serious with Emacs has ended in spending hours trying to get two or three extensions I want to use to play nicely with each other; with Vim (or VS Code), this almost never happens.
I've long suspected Emacs's greatest strength is also its greatest liability: you can do almost anything with it if you learn Emacs Lisp, but it often feels like you must learn Emacs Lisp to do almost anything with it.
> Most people new to, say, Visual Studio don't start with "How do I download plugins".
Not to pile on with the other reply, but, well: editors like Visual Studio Code, Atom, Panic's new Mac-only editor Nova, and even Sublime Text to a degree actually make plugins front and center. It's a very different approach than what Emacs and Vim have historically taken, but I think it's contributed greatly to their mindshare. VS Code in particular goes out of its way to recommend plugins to you based on the files that you've recently edited.
> If I could suggest just one change to make Emacs feel more "modern," it would be to entirely redo the Customize section to make it behave more like VS Code's preference system
It's probably not hard for someone to do that with Emacs - all the bits and pieces are there. I wouldn't be opposed to this.
> They're both difficult for beginners to get used to, but once you get over the initial learning hump, Vim was always much easier for me to tweak and configure.
At the risk of starting a pointless war, I suspect it may be because Vim just has an order of magnitude fewer features than Emacs does. Many people have wanted Org mode in Vim, and no one has been able to make a good one.
> when it comes to not stomping on one another. Every attempt I've made at getting serious with Emacs has ended in spending hours trying to get two or three extensions I want to use to play nicely with each other
I believe you because this complaint does come up from time to time. I must have been simply lucky that this has been a very rare problem for me. In fact, I often tell people Emacs is great because one can take disparate packages and use them together to get powerful features. To me it exemplifies the UNIX philosophy of combining tools better than most UNIX utilities themselves do. The worst I've encountered is a conflicting keybinding.
> you can do almost anything with it if you learn Emacs Lisp, but it often feels like you must learn Emacs Lisp to do almost anything with it.
I view that as one of the biggest myths. I was a power user for about a decade before I learned to even write a loop in Emacs lisp. The most I knew was setting the value of variables. That's enough to be a power user.
Now that I know Emacs lisp, I don't have a burst of productivity compared to when I was ignorant. I've customized to solve a few annoying problems, but I've not had any moments of "Oh man, I wish I knew how to do this all these years."
I don't encourage Emacs users to learn elisp. If I ranked things they should explore in Emacs, there would be a lot of stuff higher on that list than learning elisp (org-mode, etc).
I'm not actually sure Vim has an order of magnitude fewer features than Emacs at this point. I've made recent attempts to make good friends with both Vim and Emacs, and have experience with Emacs 27 and Vim 8. In my hopefully not too cynical observation, Vim fans tend to overestimate Emacs's complexity and capacity to be confusing (even saying this as someone who has admitted to being confused by Emacs!), while Emacs fans tend to underestimate modern Vim's capability.
I am not sure whether I just have bad luck with Emacs extensions. :) I suspect it depends on what languages you're delving into; I found trying to get HTML, CSS, PHP and JavaScript modes all playing nicely together (literally, since the same file could technically have all four, with a secondary template language thrown in for good measure!) challenging. But that particular adventure was a while ago. (My most recent attempt was with Spacemacs, which, uh, I'll just say it has some great color schemes.)
Re: Emacs Lisp: well, I did say "often feels like," not "actually is." :) I'm sure you're right; it's just that sense that a lot of early problems get solved by "to do the thing you want to do, paste this code into your init file," and getting past the feeling that you're assembling a configuration you don't reallllllly understand -- and thus may not be able to debug if something goes wrong -- can be a hurdle.
> while Emacs fans tend to underestimate modern Vim's capability.
I don't doubt vim is very powerful for things like programming, but can I use it to automatically scan my emails for keywords and make TODOs out of them (in just a few lines of code)? Can I use vim to compute derivatives of math functions and automatically insert them into LaTeX documents? And so on.
Don't look at Emacs merely as a programming editor. It's a playground for anything textual.
I don't understand why Emacs needs customisation to be useful. If it's not useful without customisation, why not ship a default 'customisation' that makes it at least somewhat useful to start with.
The article on lwn pretty much nails it. The discoverability of features would be great. I have been used emacs for ~20 years and I had finally switched to VSCode after I was stuck for half an hour finding a way to type single-quote in org-mode. I had found a way first time in the past, but then I completely forgot how to do it and was forced to search again. (It something to do with locales, it is traditional for Russian to use < > and << >> quotes instead of ' and ", so someone made it default when LANG=ru_RU.UTF8, so one types ' but gets < or >. But how it was done? How to undo this damage to emacs? Now I cannot remember it one more time, but luckily I do not use emacs now so it doesn't matter anymore).
I don't want to see any changes. There's nothing in emacs that requires any modifications or "modernization" from my perspective. But I'm nearly 57, which is why emacs, like me, will (mostly) die out.
In a generation, vim and emacs will still be around with their minuscule but loyal user bases of tinkerers and VS code will have long been replaced by something newer and flashier.
Ah, but you miss its hackability aspect by virtue of being a lisp runtime. I wouldn't say eclipse is anywhere close to "hackable" as emacs is.
Just run C-x b <scratch> RET and you have an elisp buffer to manipulate the state of the entire editor. It allows for superfast iteration, compared to the plugin development cycle of other editors. Though, vscode/javascript has definitely made it much closer to what is possible in emacs.
"Superior" for sure isn't the word I'd use, almost every one of the editors and IDEs make a bunch of trade-offs that appeal to different audiences
IMHO, the barrier to entry for modification for both emacs and vim is much lower than their competition: evaluate text in a buffer, observe change to your editor
I don't know of any other tooling has that immediate feedback loop remeniscient of the old JS in HTML (or the dev tools console, as apples to apples) approachability
I am more accustomed to vim than emacs.
Some things I painfully miss when using something else than vim : quick and easy shortcuts to jump around the file, delete words/blocks/parenthesis, place marks to jump between parts of one or multiple files, macros, filtering parts of the file through external command...
The default display colors for software have gone from green text on black background to black text on white background, and then back again in the 40 years that emacs has been on the scene.
It’s quite silly to think that dark mode is a modern invention. It’s just a example of how software trends are a form of fashion, and they do behave cyclically.
See also: return to lightweight clients and fat servers as we moved onto the web, and then moving the bulk of work back to fat clients with React etc
I think we're talking about different things here. You're talking about the physical restrictions of the media, I'm talking about the defaults selected by software developers.
My first computer could display dozens of colors, but defaulted to a dark background and light text. Windows 3.11 defaulted to black-on-white, on hardware from the same era. And now we're cycling back to defaulting to dark modes again.
You’re right; I was thinking of the text-only terminals that were widely used in the 70s and 80s. I believe those are where the green/amber/white on black aesthetic originated, because they couldn’t display anything else. But I could be wrong.
There is this one concept. I can’t get away from it. Comprehension bandwidth. Emacs is an amazing piece of software. I have probably used it more than any other piece of software over 20 years. The marginal utility of Emacs over pycharm or Gedit does not exist. Most programmers, if they are being honest, can be just as effective in notepad. Modern IDE that understand their problem domain provide much more utility. These are simple facts. We type characters, they do stuff. It don’t take a fancy editor to do that.
It feels like a spring loaded bundle of magic that will explode if I look at it wrong, and, having exploded, I will never ever ever get it put back the way it was.
A craftsman makes his own tools. Not all of them, but some, whenever they see a possible improvement, or their work is novel.
It's the assembly line worker that doesn't, and sticks to using the company-provided "industry standard" tooling. The assembly line worker doesn't need to make custom tools, because he/she has no agency - the worker's role is just to close a feedback loop in a well-defined industrial process of mass manufacturing a fully specified end product.
I know a fair number of craftspeople. The only one who made their own tools was my brother, who wound his own heater coils for his glass annealing furnace because it was too expensive to buy. Similarly, the only time I design a custom LED light is if I cannot buy what I want. And I'm really good at designing LED lights, I've been doing it for fifteen years.
If the goal is to make furniture, or a glass flask, or a pair of socks -- why would you think those skills overlap with the skills required to improve a band saw, build a torch head, or manufacture knitting needles? They're not even using the same broad area of skill.
It is lucky that you can change software so easily, but I think calling anyone who doesn't feel it is a good use of their time to customize one tool instead of just using a different one an "assembly line worker" is quite insulting, mastering a tool doesn't necessarily require being able to manufacture it. I could not manufacture a pen but I'm pretty good at writing =P
By making your own tools I don't mean making your own knitting needles or torch head - though some do that too. I meant making custom workbenches, custom harnesses for the parts you're working on, modding the tools to be more ergonomic or to serve a different purpose than intended, etc. This is all "making your own tools" too.
I have a woodworker in my family and from what I observed watching him at work, he mods his tools for ergonomics, and if the piece he's working on is tricky to use with his machines, he constructs the necessary affordances to make it easier.
Similarly in programming, you won't get far if you only keep to what your IDE offers you out of the box. Configuring your IDE, writing scripts, writing software that automates your work - it's all part of the craft.
I wouldn't call anyone who doesn't feel it's worth the investment to customize something an "assembly line worker", it implies that they aren't doing creative work with the tool because they happen to be more focused on the project than the tool. It's just insulting and I don't get why you'd bother to go that far.
I also don't know why you'd draw any kind of line at "modified own tool". Building your own 3d printer doesn't make you creative if you're using a kit, it's the parts you make that are creative or not. Classify based on what someone is doing with the tools, not the tools themselves, that's just a cargo cult.
I admit the comment was phrased in an unnecessarily inflammatory way, and I apologize.
The point wasn't to draw a line between "programmers - craftsmen" and "programmers - assembly line workers", but to highlight that programming is very much craftsmanship, and because of that, I disagree with the thought "I am a craftsman, not a tool maker" in the comment I replied to. A craft is almost by definition something that isn't streamlined to the point you can reasonably only focus on using tools you're provided. There's always a benefit in doing meta-work - work to make your work easier. This applies to programming much more than other crafts, because the skill set you need to build tools is literally the same as the one you use for working with those tools.
Also note that the comment didn't say the assembly line workers aren't creative (though on a perfect assembly line they can't be creative at work, by definition) - but that the type of work doesn't leave much space for bottom-up improvement.
> Building your own 3d printer doesn't make you creative if you're using a kit, it's the parts you make that are creative or not.
If building your own 3D printer lets you shorten your iterations compared to your old process of sending CAD drawings to some company and waiting a couple of days, thus saving you effort and money, then building that printer from a kit is very much worthwhile and it's what I'd expect a craftsman would do. Too much focus on the work immediately in front of you is bad too (see also: greedy algorithms). This whole topic isn't an issue of creativity, but pragmatism.
I'd argue you're not a true craftsman until you've started making your own tools, or at least tailoring generalized ones, to better suit your personal workflow.
No, there are certain features and terms in Emacs which makes it very alien to the modern world. Things like the cursor being limited to the visable part of the buffer, the usage of "window" for a buffer and "frame" for an application-window. Also the way Undo/Redo works and such.
If you really aim for a modern Emacs, then forking it and fixing it from the ground up might be not the worst idea longterm.
Emacs is so old that it has accumulated quite a number of old cruft and debt.
So I agree in part with your point that emacs doesn't really need to change their UI/UX (new menu, new shortcuts, etc). The Emacs model takes time to learn and is different from the rest of the world, but it works quite well once you take the time to learn it. That's not for everybody, not necessarily beginner friendly, but that's fine, emacs is a quite advanced editor environment, it has its own niche of users.
But some things make emacs just a bad editor, even for people who did spend the time to learn it. For example emacs is horrible at dealing with big files. The entire editor is stuck for seconds if you open a log file with just a few megabytes of content. Emacs performances are also really bad when compared to other editors, simple syntax highlighting or intellisense is just really, really slow.
I used emacs for years as my main editor because I was happy to have something stable, because I love lisp, and because I really like the introspection and control you get. But at some point I realized how fast and way more advanced other editors were in comparison to what I could get with a tuned emacs environment and jumped ship.
Even keeping the emacs UI and UX there is a lot of modernization that can be done under the hood to make it up to the task of the modern world.
I just tried opening a large (11 MB) log file on a 2008 netbook and, except for the unexpected "File is large, really open?" question, the load time seemed instantaneous (Emacs 26.3, Lubuntu 16.04).
Even if they are not enabled by default, I think having these features would be nice and would be helpful for emacs distributions to really take off more than they currently do.
Something like spacemacs and prelude would have a much wider adoption if there was a mode that can be enabled to make the learning curve smaller, the look / themes better, ui more intuitive.
The author seems to confuse "better" and "more like others". The colors are a clear example of the latter, the developers didn't choose a light theme back then because dark ones weren't invented yet or because computers weren't powerful enough for them. Things like the completion UI may be a different story.
I don't think emacs needs to change but I also feel like there are some concerns that need to be addressed for a new and rapidly growing generation of programmers who aren't learning to use emacs and vim. While it might be thriving now, we're probably 10 or 20 years away from emacs being extremely niche (more than it is today).
I would like it to be multithreaded and for Org mode to have some more UI features (and I think a lot of people would - at least the former). From what I understand it's really hard to do that by building on the existing C base ELisp base.
Unpopular opinion: we should write the "new" Emacs in Julia (and maybe Rust).
As for Julia, I mean I like the matlab like syntax for data science use, and I’m sure its great for prototyping computation heavy algorithms where run time dwarfs the JIT lag, but its surely not suitable for a text editor, at least at present. I’ve tried Julia several times as new versions of have been released and for simple scripting tasks that required a few external libraries I’ve always ended up rewriting the script in Python because the scripts were faster to run from start-up, more consistent in performance (no unexpected pauses to re- pre-compile) and simpler (no messing around getting packagecompiler.jl working etc).
My experience has been the opposite: things have been much easier and faster to set up in Julia. Yes, "time to first plot" is annoying after you update the plot package, but that's the only annoying thing for me.
Julia is a thinly disguised Lisp, offering all the wizardry associated with that language family - so it's very expressive.
The main problem with emacs is that while it's praised for being a programmable lisp environment, it's not a really good one.
It doesn't have widgets, decent rendering engine with scene graph and hardware accel, it's single threaded, the language is clunky. You really can't make decent applications in emacs, only text with embedded images and primitive buttons, that blocks and stalls all the time.
But the funny thing is Emacs has neither of those. There is no real "API" or "plugin system". Just code. You can copy a function off the internet and paste it into editor and now it is part of your Emacs. And you can modify any of the existing code as much as you please. That is the lesson of Emacs.
I don’t see that as a benefit, I see that as an accident. The fact that the whole thing is a hairball isn’t how editors two centuries from now will be. But it is an approximation to a modern system.
Emacs is one of the most successful text editors of all time if not the most successful. It is widely used for a staggering array of tasks.
It is over 40 years old.
When I see a highly successful 40+ year old piece of software, my first instinct isn’t to ask what the people behind it can learn from me but what I can learn from them.
I’m not saying the editor can not be improved. But I think the bar is much higher than this. It’s not an insult to say something like emacs is not “modern.” Of course it’s not. And changing the colors? The shortcuts that have worked for decades? Please.
If someone thinks emacs will be more successful with these cosmetic changes they are welcome to fork it since this is one of the earliest open source programs. Code talks, a bunch of people opining on a mailing list is pretty worthless in comparison.