Toward a “modern” Emacs | Hacker News Reader

Toward a “modern” Emacs

lwn.net

286 pointslukastyrychtr523 comments

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.

You don’t even need to fork it. Just have write a .emacs file that new users can copy to their home directory that sets all of that stuff up.

I think I still have the .emacs file I inherited from an upperclassman. It had better syntax highlighting than what was built in at the time =)

See, this is what I hate about emacs.

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.

Or you can learn about the magic and wield it.

I am a craftsman, not a tool maker.

Yeah, I'm with you on that one. I would definitely not have created my own from scratch, and I even knew scheme at the time.

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.

Don't worry, magit's got your back.

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.

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

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.

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.

I don't think many people are using Vi. Its more likely they are using vim or neovim, which are both far from clunky.

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.

Many of us switched to evil mode because we got RSI from incorrectly chording all the time! C-a & C-e I'm looking at you

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.

In this case, it isn't about money, but proficiency.

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?

Slower to learn, but with a higher cap, and more likely to endure for four more decades than a given learn-in-two-weeks gui program.

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"?

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

Heh, most of my emacs shortcuts start with ;

Perhaps ironically, mac OS text input boxes are where I use most of the traditional emacs C-/M- keybindings these days.

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.

Funnily enough, Bill Joy (creator of vi) said he would have made a modeless editor if he had thought of it, he just didn’t.

I use vi-family editors for the same reason I use grep: it’s installed everywhere. I’m not religious about its benefits.

Nov.el is my favorite ebook reader.

Just to add links to the SO surveys mentionned here :

- 2019: https://insights.stackoverflow.com/survey/2019#development-e...

- 2018: https://insights.stackoverflow.com/survey/2018#development-e...

- 2017: https://insights.stackoverflow.com/survey/2017#technology-_-...

- 2016: https://insights.stackoverflow.com/survey/2016#technology-de...

- 2015: https://insights.stackoverflow.com/survey/2015#tech-editor

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.

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.

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.

I remain utterly perplexed by the popularity of VS Code, to me it basically does nothing well, but does a bunch of things mediocrely.

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

Yeah but VS Code is considered by many to also be best in class.

To each their own :)

I find that assertion utterly perplexing.

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.

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.

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.

OS X is about 10% of the world desktop market.

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.

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.

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.

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.

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

They probably just send a newsletter to StackOverflow users :-)

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.

I do that. Just unwanted = unsubscribe; unexpected = spam; if unsubscribe link doesn't work or requires logging in => spam.

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’m nearly 40 and I’ve used it as my primary text editor since I was a teen and daily for my job.

For your anecdata collection.

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've heard people say that, but what I find is that they pick shitty names and never refactor. I'm on a different team now. Most of us use vim.

Yeah, but then when someone tells you in code review to pick a less shitty variable name, it still takes one click.

Sadly, when you get a reputation for giving that feedback, people stop asking you to review.

Damn. You must work on a shitty team.

I'm on a different team now.

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.

I don't do a lot of java development but https://github.com/emacs-lsp/lsp-java works really well for me.

This is amazing.

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

Isn't Boston where MIT is and where Stallman lives?

Also, Berkeley as in BSD.

You're probably living in a smaller bubble than mine :-)

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.

I am using Vim. Is it worth it to try emacs?

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.

Try doom-emacs, consequently evil-mode and highly adaptable. https://github.com/hlissner/doom-emacs

I used to use Vim, but switched to Spacemacs and never looked back. I highly recommend it as it gives you Vim bindings with all Emacs possibilities.

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.

- undo-tree-visualize.

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.

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.

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.

What language? Some languages have Emacs usage in the range of 0%, such as Java and C#.

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

It is fairly common with C programmers, and C++ programmers outside Windows ecosystem.

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.

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.

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

Yeah, we European Emacs users went to the states to earn real money :^)

Uh ... That was a punch. Love it :)

Well, one Eastern European Emacs user here. :D

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.

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?

[0] http://www.cse.chalmers.se/edu/year/2017/course/DAT350/

[1] https://wiki.portal.chalmers.se/agda/pmwiki.php

[2] https://agda.readthedocs.io/en/latest/tools/emacs-mode.html

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.

I have a feeling the SO numbers aren't accounting for Org Mode users.

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.

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.

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.

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.

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)

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.

but how is % usage related to tasks ?

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.

Strange, I feel like I'm in a minority among physicists for using vim instead of emacs. Many new students seem to prefer GUI editors though...

Makes me happy to hear some physicists still use Emacs.

- Former physicist turned programmer

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!

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.

The Prelude package uses dark mode to give Emacs a modern look. And adds line numbers for the same reason - LOL.

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've used Emacs for 33 of those 40+ years, and I agree with that until the word "without".

You don't mean "modernization". You mean "without it changing". And the answer is yes, it will die out.

What are some of the changes you would want to see?

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.

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.

> Surprising undo model

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.

> a lot of people use Emacs for all kinds of things unrelated to programming: TODO management, document authoring, writing emails, etc.

Those still need addons/plugins like org, mu4e or some other mail client, etc. This my point — not just a vanilla text editor.

Org is part of a standard Emacs install since version 24.

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

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.

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.

Would you have decided to learn Emacs if you didn't already use it?

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.

Proper multithreading/tasking.

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.

I am in my early 20s, not exactly "young" I suppose, but I have been using Emacs since age 11. I think it is fine the way it is.

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

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.

Why? How are either of them superior to VS Code?

I can run them on a breadboard.

An exaggeration, but not a large one.

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

I know, “memory is cheap,” but still...

Well, Eclipse has had practically two decades of vi/emacs users shitting on it and yet it is still popular enough to warrant an entire conference.

https://www.eclipsecon.org/2020

Isn't Eclipse basically the modern Emacs?

It's a plugin management system that happens to be shipped with a set of plug-ins targeted at serving as an IDE, written in Java instead of Lisp.

> Isn't Eclipse basically the modern Emacs?

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.

You're on the right track. There are really 3 editors in the world: Vim, Emacs, and <bbedit/eclipse/textmate/sublime/atom/vscode/etc./etc.>

Yes, VSCode will be replaced by something newer and flashier, but the learning curve to switch to it will be minimal.

You forgot my favorite (before discovering Emacs), Notepad++!

When you've been warned the world will end and ~~notepad~~ VS code will take over for 50 years you tend to become blase about the whole thing.

Emacs has a steep learning curve and that's good. You need a moat to keep the barbarians from destroying your kingdom.

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

I will check it out in 10 years if it's still around. In the mean time I have actual work I need to get done.

> In the mean time I have actual work I need to get done.

That's probably how most VS Code users feel about learning Emacs after reading about it on HN :)

I doubt they have had 20 years of using to it though.

Certainly, but that's where the not-so-steep learning curve helps.

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.

Does emacs even offer anything like `vimtutor`?

> Does emacs even offer anything like `vimtutor`?

Yup. And iirc it's more discoverable than vimtutor because it's on the first page of the vanilla Emacs

>Does emacs even offer anything like `vimtutor`?

https://i.stack.imgur.com/egD8V.jpg

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.

> releasing a space cadet mechanical keyboard

The mechanical keyboard community will probably get there first.

From a quick search, I've found this [1], which goes a bit beyond the original Space Cadet keyboard.

[1] https://yiancar-designs.com/portfolio/hyper7/

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.

https://www.reddit.com/r/MechGroupBuys/comments/j3pmmn/gb_gm...

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.

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

Found Spacemacs to be slow and buggy, Doom's fine so far though

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.

> Emacs has a steep learning curve and that's good. You need a moat to keep the barbarians from destroying your kingdom.

Most of the emacs community radiates that same attitude, which is one reason it stays where it is and doesn't flourish.

Yes, it's wonderful the community is small and technically capable.

A community can be technically capable without being full of elitists. Just look at Clojure.

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

And that exact attitude also drives away people who could handle and enjoy Lisp just fine, just not unwelcoming elitism.

Yes, it's a feature, one we should use a lot more of.

Someone that thin skinned would demand that the project accommodate them, try to take it over and then run it to the ground.

After all it's not like Stallman didn't become homeless because of people like that.

Can you please not do programming flamewars on HN? It's low-quality discussion and it has poisonous effects on the community.

https://news.ycombinator.com/newsguidelines.html

> "VS code is rapidly taking over it's niche"

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.

[1] https://vscode-eastus.azurewebsites.net/blogs/2017/11/16/con... - (VS Code has telemetry built in, so Microsoft has some accurate idea of numbers, even if they still have the incentive to hype them up a bit).

[2] https://en.wikipedia.org/wiki/Visual_Studio_Code#Reception

[3] https://code.visualstudio.com/blogs/2020/06/09/go-extension

[4] https://github.com/microsoft/vscode

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

ibuffer is part of the standard distribution, it's just not called by C-x C-b by default (that's bound to list-buffers instead).

Sorry, turns out I was thinking of ivy-switch-buffer, not ibuffer. You are absolutely right though.

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.

>I’m not saying the editor can not be improved.

Just not on your lifetime.

The lesson is to be the first editor with an API and plugin system. That’s the trick. It’s like QWERTY.

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.

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

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.

A little messaging about starter-pack options, in the default welcome screens, would go a long way.

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'm sorry, I don't understand the point that you're trying to make?

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

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.

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.

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.

> There will be major new areas of innovation

I’m really curious what you mean by that, and how you see the world evolving such that Emacs, as is, won’t be able to come along with it.

Imagine a world where your terminal isn’t emulating a TTY from fifty years ago. Gary Bernhardt gave a talk about this in 2012[0].

[0] https://www.destroyallsoftware.com/talks/a-whole-new-world

Pretty cool talk! I love some of the features he's added!

https://imgur.com/Gtytll1

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.

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.

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.

Doom emacs is probably the state of the art emacs starter pack now. A lot faster than spacemacs, more stable etc.

A rock solid default config made out of Doom emacs might work.

I don't think a starter pack that completely disables the "Customize" interface would be a good candidate for default.

https://github.com/hlissner/doom-emacs/blob/a2a5038b970df20e...

"Doom doesn't support `customize' and it never will. It's a clumsy interface"

I find the Customize interface very useful.

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

When you use the customize interface you sacrifice proper version control.

Bad idea.

You can include custom-file in version control easily enough.

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

And how do you arrive at the correct values for 'foo' and 'bar'?. The key feature of customize is discoverability.

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.

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.

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

Later I found a talk which expresses the same sentiment in it's title: "The Editor of a Lifetime" https://www.youtube.com/watch?v=VADudzQGvU8&t=1823s

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.

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.

transparency, gradients and rounded window corners.

oh, and a thin sans-serif font.

maybe a soundtrack

Can we move Emacs into the cloudchain somehow?

init.elcc

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.

It really needs some major update.

I don't think Emacs needs to be GTK

Emacs needs to be contemporary framework, implementing modern ideas of how to organize and optimize stuff.

Software engineering and hardware advanced a lot in the previous 40 years in all the directions: PLs, GC algorithms, UI rendering.

If Emacs wouldn't be a contemporary technology, people would simply choose another editor.

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

Green on black was not exactly a “software default”. It was a physical property of the display hardware.

Dark on light is at least thousands of years old, think of ink on papyrus in ancient Egypt.

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.

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

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

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

> Emacs is one of the most successful text editors of all time if not the most successful.

Define success.

> But I think the bar is much higher than this.

Sometimes it's the small details who have the biggest impact.

The article makes some interesting points, to me, though, I think the Emacs devs need to have a discussion with themselves if they even want to go here.

Here's what I see as an outsider if I'm a Windows users and want to give this great emacs editor I've heard so much about a try:

First off, I search for emacs, I land on a page with a Windows link. I click that link, I get a rant about how Windows is evil.

Ok, fine, sure, gnu and all of that.

Then I follow a link to download it from a mirror. That link doesn't actually lead to a download, it leads to a directory on the mirror that I need to drill down into another directory. The README in this directory contradicts the emacs website on which version I download. I go to download the installer, if I try to run it, I get a big scary warning (I can't blame GNU on this too much, but still, more friction). Finally, I have emacs on my machine. (If I follow the directions on the webpage, I download a zip file, and I'm left wondering why I should run "runemacs.exe" and not run "emacs.exe". I know why, but dang it, this is just silly)

I run it. I'm presented with some combination of a text UI and iconography from the 90's. I get emacs doesn't change much, but this adds to the sour taste already building.

And then there's the intro, which is what this article is touching on. The first thing it teaches me is some odd-for-me commands to navigate that as a user are all new and unlike every editor I've used.

Now I decide to play around and open a file. Do I want to "visit new file" or "open file"? I pick one, and it helpfully defaults to showing me files in the emacs installation folder. Great.

And by this point the thing has beeped at me a dozen or so times for reasons known only to emacs, and I'm tired of it all.

Emacs is clearly designed for people that use emacs, and that's fine, but if you want to get more mindshare, you'll need to, first thing, ask me if I want to set it up to act like VS Code or IntelliJ or Emacs.

> it teaches me is some odd-for-me commands to navigate that as a user are all new and unlike every editor I've used.

That is the point. If it worked the same as every editor you've used, why switch? The point why Emacs is better is because it's different. These things need to be learned. Otherwise, Emacs can't help you.

It would be like people complaining that playing a guitar is different than pushing the play button on every music player they've ever tried. Well, yes, that is the point.

Really? The point why Emacs is better is that it has different keyboard shortcuts?

That is what I never understood -- I've implemented exactly this "which editor emulation do you want to use" and "edit your own bindings" for one Windows product containing editor in early nineties. It wasn't hard. The default was, of course, the "least surprising" for the platform, but it also allowed other popular editors then. If there's anything that can reduce friction to the new user, it's that: a beginner can use the actions he already knows how to do. Let him just the ability to access those that are unique -- for these he anyway doesn't have any reflexes.

My biggest eyeroll whenever I looked at Emacs "help" (or any other, Emacs is not unique in that approach) was "and then you use Meta key." Well I don't think that anybody bought a physical keyboard with a key on which it was written "Meta" for a least 30 years. How about recognizing that for the beginners?

https://en.wikipedia.org/wiki/Meta_key

"But, meta is not always the same key" I hear every time -- fine, but that should also be the part of "advanced stuff." Just let people know that they initially have Alt, Ctrl and Escape where on the keycaps Alt, Ctrl and Escape are written.

In Emacs, you can configure literally anything, including the keybindings. Some people use Emacs with Vim keybindings (Evil, Spacemacs, Doom).

Now, for me, typical Emacs keybindings, of which the majority is defined in 3rd party packages are very logical, while Vim's are not. But the users who prefer the Vim way did they work and configured Emacs however they liked.

OTOH, of the million people who complain and ask for Ctrl+C for copy and Ctrl+V for paste and whatnot, I've never seen anyone who did the 2 minutes or two hours of work, went into a configuration, and changed these keys. Why's that so, if that's such a great idea?

Probably because having the default be something other than what a user is used to is not going to compel them towards doing the research to fix it.

In order to get cua-mode working in emacs, you first have to know that it exists. I didn't know it existed for like two years of daily emacs usage, I just can't find it in myself to expect someone to know about it after 10 minutes.

By the time you know it exists, you've already accepted the keybindings and you've already put in the time to build some muscle memory, and it doesn't seem as important anymore.

The fact that some people get past it isn't really an indicator that it isn't a huge friction point.

Perhaps, but out of the million and counting know-alls, who:

1) claim they know a thing or two about emacs

2) claim that the biggest problem emacs has is CUV

3) demand that change from the core Emacs team

exactly zero people created a CUV-emacs configuration, and gifted it to the world.

I think that's telling.

Keep in mind that all three combinations are central to Emacs

1) C-c is used in million combinations 2) C-u too 3) C-v scrolls a page down.

This is _very_ surprising. CUA mode is called out as the fifth item in the options menu, and the menu description itself describes what it offers.

"Use CUA Keys (Cut/Paste with C-x/C-c/C-v)"

It doesn't require any knowledge of lisp at all (contrary to the assertion in the LWN article), and you don't have to know it exists, at least not any more than any other option in a menu requires that.

Ctrl+C and Ctrl+V are only two bindings, it's hardly a big deal. But I've used Emacs for decades, and I expect a lot of control-key bindings, to the point that remapping the CapsLock key as an extra control is a vital part of making a computer usable.

Do other editors have the CapsLock binding problem, or do they generally rely on something other than control keys?

> I've never seen anyone who did the 2 minutes or two hours of work, went into a configuration, and changed these keys.

I believe it's true: I don't think anybody could even dare trying to change the key combinations if all the help pages can help you only with the description "META v" means "scrolling down in x jumps" or whatever.

In that case one spends time figuring out that these weird pages write each time "META" instead of writing... I don't know what... and then one just "translates" in head each time, cursing the "help" for not being direct. But changing the combinations to make even such "help" even more unusable? No way.

The complete mindset would have to be different across all tutorial and references to avoid "hardcoding" the key combinations even there -- the "proper" help would reflect the environment as chosen.

The beginner's expectation is that all trivial interactions could be done the way he's already used to perform them, and the "power" of the editor is not in pressing combination a or combination b, but in the functionality which is not present in other editors.

For the context: One of my oldest muscle memories are key combinations of Wordstar, a character-based text processor. The the editors on DOS and later Window which targeted programmers had for years default key combinations which imitated Wordstar, or allowed to select them once for all. But most people from that times unlearned these combinations once they started using Windows GUI, expecting that all GUI interactions use the GUI common key combinations, like holding shift and moving cursor using the arrow keys to mark the selection. Some convention came from the traditional Mac OS, initially Windows started with some other combinations than Ctrl-C, Ctrl-V, but I've never used these older Windows-unique (Shift-Insert or something). Of course on Linux GUIs it can still be a mess:

https://askubuntu.com/questions/26655/how-do-you-know-when-t...

where sometimes one work and another not when clipboards aren't "shared" with installing some additional program that does that. So let's not go there. Considering the more "stable" GUI platforms (which sometimes also, unfortunately, aren't: some special "clipboard managers" are introduced there too in different occasions) the editors should "fit" to them as much as possible.

Is there is any tutorial "start using Emacs based on what you already know when using Notepad, without having to unlearn the basic operations with the keyboard"?

At the end a "normal" user just wants to do his job. If some tool allow doing what other tools don't, that's the reason for the tool.

Editors, once they become "the environment" for work are however also not normal tools. If the whole production in some company is based on some set of tools, one will accept them "just to get the job done" since anything else would mean even more unnecessary effort. That's how some people learn vi, for example, reading the HN posts. They join a team where it's "how the job is done".

How many typical Notepad users use ANY shortcuts as the basic keyboard operations? I'd say a tiny minority. A typical Notepad user that I've seen uses the mouse exclusively, and clicks around menu. Yes, that includes copy, paste, and save, the three operations that you'd think everyone would perform on keyboard. But, say, 50% of the users don't even do that. For 40% these three shortcuts are pretty much everything they do on the keyboard. The rest is the mouse. Perhaps, 10% are the users who only ever open Notepad, and try to use muscle memory from a more powerful editor.

Is that bad? No! From the perspective of unlearning, it's ideal! The problem that Emacs has is not so much that tyical Notepad users have to unlearn a ton of stuff, it's that they are not so eager to learn anything keyboard-oriented.

No amount of crippling Emacs would help there. It can only spoil it for existing happy users. As people mentioned in this thread, there are things that are aging (large files, freezes, whatnot) but the keybindings is something Emacsers actually like.

> No amount of crippling Emacs would help there. It can only spoil it for existing happy users.

I am surely against "crippling."

The initial topic of the discussion was how to make Emacs accessible to the new users. I don't suggest making fixed changes to anything, only allowing somebody to easily select different defaults which correspond with the keyboards available today. Today's keyboard has no meta key. Old keyboards didn't have a lot of keys that today's exist and have expected behavior in GUI -- potential Emacs user should have a possibility to turn on "consistent" behavior for everything that can be consistent, and the help should be easy to read without having to divine what META key in the "easy" case could even mean.

Of course the old users should be able to use old behavior.

But that is certainly not only possible, but available today in Emacs. It's here. Use it and evangelize it if you like.

What I talk about is what "amadeuspagel" also describes in a post here.

And to confirm that experience, until participating in this conversation, I also didn't know that it could be possible to efficiently use Emacs with the key combinations of some "more familiar to common people" editor.

And I'm still confused: if you say "Keep in mind that all three combinations are central to Emacs 1) C-c is used in million combinations 2) C-u too 3) C-v scrolls a page down."

What then? Does it mean that I can't use the "million combinations" if I want Ctrl-C to mean copy? What is then the start of "a million combinations"? Why should't help system simply adjust to display the "start of million of combinations" as the thing I selected at the start? If I like Ctrl K instead, couldn't that be "the start of the million of combinations"?

And why should I care that "C-v scrolls a page down"? The keyboards since at least 1987 have a physical "Page Down" key, why should I not use that then?

(And they surely don't have a physical "Meta" key).

I hope that's a usable example of what confuses at least one kind of a beginner.

If you open VS Code for the first time, it asks you immidiately what keyboard shortcuts you want to use. When you open Emacs, you see a tutorial that tries to teach other keyboard shortcuts, and not a hint that you can change them, let alone how.

For me the killer feature of using emacs on a Mac is having a dedicated command c/v/x/z for copy/paste/cut/undo that's separate from ctrl c/v/x/z in emacs (and readline shell bindings in general).

Nope, it's the ecosystem around them.

Emacs has a lot of selling points, but the keybindings aren't one of them.

I spent weeks trying to switch, but ultimately I found the experience frustrating. UIs follow the same patterns for a reason, it makes it easier for users to adopt the tech.

The biggest draw for me was org-mode with org-babel. I've never seen anything else like it

> Emacs has a lot of selling points, but the keybindings aren't one of them.

I find this difficult to understand for people who use the terminal. The keybindings are the exact same for most terminals by default, since they use readline. Want to go to the end of your command? `Ctrl-E`. Want to go to the beginning? `Ctrl-A`. Want to search backwards through history? `Ctrl-R` (same thing you would do while searching backwards through an Emacs buffer).

All of these also happen to work everywhere in MacOS. Put your cursor on the URL and press Ctrl-A and Ctrl-E.

Personally, out of those I've only used Ctrl-R in the terminal. I just use the Home/End keys to navigate to the start/end of lines. I was actually surprised to read that Ctrl-E and Ctrl-A would do that. I usually expect Ctrl-A to select all, and don't really expect anything from Ctrl-E. (Though, I'd be surprised if home/end didn't work in Emacs, I'm just saying I've never used those readline keybinds).

Home/End should go to the start/end of the file, not the line.

Oh you’re a Windows or Linux user? Too bad, now you need to get used to modern key bindings like OS X has.

It is not bad. Ctrl+Home, Ctrl+End.

Get out of the apple cult.

I don't use OS X. I do use Emacs. I don't use CUA. HN has trouble with metaphor.

> I just use the Home/End keys to navigate to the start/end of lines.

If true, my guess is these were added to the shells recently (e.g. last 15 years). When I started using Linux (in the 2000's), these keybindings didn't work. It was Ctrl-A and Ctrl-E. I'd love to do a survey to see how many shell users use these vs Home/End.

I'm pretty sure the number of shell users has grown exponentially in recent years. I wouldn't be surprised if most users wouldn't know them.

However, the more one uses the shell, knowing those emacs shortcuts really helps (not just Ctrl+A, but also going forward or back one word). Especially on a show connection.

The saddest thing is its easier to just install it from WSL and use something an X server and it runs faster.

But Windows IS evil...

Please don't post flamebait and/or unsubstantive comments to HN. We're trying for something different here.

https://news.ycombinator.com/newsguidelines.html

I recently setup Emacs on a Windows work computer and the install process is definitely needlessly difficult. Other "popular" editors have a big download link on the homepage while Emacs you have to scroll through the lecture on non-free systems, and then link to an ftp server where you have to try to figure out which file you need to download.

From the Emacs install instructions:

"Nonfree systems

The reason for GNU Emacs's existence is to provide a powerful editor for the GNU operating system. Versions of GNU, such as GNU/Linux, are the primary platforms for Emacs development.

However, GNU Emacs includes support for some other systems that volunteers choose to support.

The purpose of the GNU system is to give users the freedom that proprietary software takes away from its users. Proprietary operating systems (like other proprietary programs) are an injustice, and we aim for a world in which they do not exist.

To improve the use of proprietary systems is a misguided goal. Our aim, rather, is to eliminate them. We include support for some proprietary systems in GNU Emacs in the hope that running Emacs on them will give users a taste of freedom and thus lead them to free themselves.

Windows

GNU Emacs for Windows can be downloaded from a nearby GNU mirror; or the main GNU FTP server. Unzip the zip file preserving the directory structure, and run bin\runemacs.exe. Alternatively, create a desktop shortcut to bin\runemacs.exe, and start Emacs by double-clicking on that shortcut's icon."

The biggest threat to Emacs is a number of hard to fix performance issues. Like rendering of very long lines. Luckily for Emacs other editors have their own performance issues, but their architectures might make them more fixable.

The other issue is the display model. Rendering using browser technologies enables other editors to do things Emacs just can't.

I'm sure some gimmicks might bring in more users. But implicit in this kind of thinking is that Emacs is perfect as it is and with right marketing it will explode. I sincerely doubt this. The biggest problems are pretty fundamental.

Just today I edited a file which basically consisted out of a line with almost 2 million characters, my emacs was basically unresponsive for a longer time. This amount of data shouldn't slow down a modern machine that badly.

M-x find-file-literally

What is this supposed to change?

Honestly it's the package management that is the problem. VS Code is also kinda slow, yet it's popular because it's so easy to discover and download plugins.

Emacs has packages too: M-x package-install

Or install & configure in .emacs:

    (use-package projectile) # :ensure is enabled

There's this response that VSCode is just another editor in the vein of Sublime/BBEdit/Atom, that will be killed by a newer, shinier competitor, while emacs persists. That's a great story—indeed it was told to me by a teacher who proselytized emacs.

But what if you're wrong?

What if VSCode is a massive challenger? For one, no editor has had the backing of a major tech corporation. Sure, XCode and Visual Studio exist, but they were specific to a particular stack. Second, language servers aren't something that can be elisped away. Stuff like multiple cursors are a few elisp lines away, but real, semantic knowledge of code is a lot harder to replicate. Emacs has language server clients but man they're annoying.

I'm an emacs user under the age of 40. All the other ones I know stem from this one teacher who taught emacs. I'm not sure how many more there are. Emacs is a fun editor and I'll certainly use the keybindings wherever I go, but it baffles me that people can look at emacs and think it's accessible at all to beginners.

Go ahead, try downloading emacs (have a fun time figuring out which version to download for macOS) and using it without any config. It's terrible. Bland, plain white, looking like it's from the 70's. M-x just dumps you into an empty text box with no help. Navigating directories involves typing out entire directory names. Getting basic stuff like goto definition requires either setting up eglot/lsp-mode or ggtags.

Emacs is great if you invest the time, but it's getting less and less clear whether the investment is worth it. To return to my question, what if you're wrong? Emacs will die. This wouldn't be the worst fate. It's had a long, respectable life. But I'd miss it.

> no editor has had the backing of a major tech corporation

Eclipse was supported by IBM since the beginning (in fact it inherited the ideas from IBM VisualAge Smalltalk).

Eclipse falls under the "for a specific stack" category. Sure, you could probably write JS and Ruby in it now, but I doubt you could 18 years ago

> Stuff like multiple cursors are a few elisp lines away...

Last time I tried to get multiple cursors/selections working, it was definitely more than that, and the result was awkward and cumbersome at best. The problem is that everything else is written assuming that there's one cursor and one selection, so you can't really make a multiple cursor system in Emacs that integrates with everything else; it remains a special case.

I've been an emacs user for more than 20 years.

Is it just me, or is this article completely missing the point?

I've switched to VS Code because I can install extensions so easily. Getting a theme installed is not my concern at all.

With emacs, I'm still never sure how to get elpa (or why not melpa) to work correctly. And, modern packages for react never seem to be available there anyway.

I'm still astounded package management is so bad on emacs.

For the record, emacs and tmux are still the first thing I install on any new server. I still use emacs on a daily basis. But, not on my desktop Linux machine anymore.

Have you tried the “straight” package manager? Quite nifty.

I agree. straight.el is the only thing that makes emacs package management usable for me.

use-package has basically solved the package management problem for me in Emacs.

use-package can make package management easier, but using it s not beginner friendly. As an advanced Emacs user, when I read its docs, there were too many subtleties that can trip up a beginner.

Indeed, just yesterday I stopped using use-package for one of my packages as I couldn't figure out why it wasn't behaving properly - reverting to require solved it.

The Emacs docs are absolutely horrendous, they read like they're written for the core dev team. Useless as an introduction, everyone ends up on Xah Lee's site.

They could be completely fixed by just providing examples of all these esoteric elisp functions.

To add packages, but to remove them...

I've been gradually switching towards completely using IDEs for like 8 years now, and in the past 2 or 3 I've broken free completely. Some of my symptoms are the same as yours: Frustrating package management, obvious missing gaps in functionality.

My conclusion is slightly different: I don't need a text editor anymore. I need an IDE and it's a bonus if it's a good text editor.

Efficient text editing is nice. But I spend a lot of time jumping between files, looking up definitions, reading documentation, tracing through code, debugging, comparing tests and regular code, etc. Plus all of the features that you expect: (colorblind-friendly) syntax highlighting, syntax highlighting, linting, etc. This is where the package pain comes in. I don't want to figure out how to configure the cross product of "every single IDE feature that I need" and "every single language that I use." I gave up. It's too much. I want my environment to either do it by default, or install a single plugin per language and never think about it again.

I'm not sure how Emacs can get "more modern," because being modern would likely start from the premise that you'd need to allow the core innovation of IDEs. They provide a pluggable framework to get uniform behavior across every language that you use. That ship sailed in Emacs - how do you move away from 40 years of "we ship a vanilla experience and you customize your environment completely to your own liking"?

I really like using Emacs but as soon as I touch a big project I need a point and click friendly IDE with refactoring/smart search support to keep my head from spinning. It would be great with some vanilla autocomplete with a language server thing that "almost just works".

What’s extending VS Code like compared to Emacs?

The amazing thing about Emacs is that you can run a snippet of elisp from anywhere at any time. I never found this to be a major advantage of Emacs for my own workflow, but if it matters to you, editors like VS Code won't cut it.

The more structured approach to building extensions in VS Code prevents namespace issues and improves robustness at the cost of runtime flexibility.

I occasionally use the Python console in Sublime Text to achieve the same thing as the Emacs scratch buffer, but Sublime also has more structured plugins than Emacs. I guess it's also technically possible to pop open the JavaScript console in VS Code, but I don't think that's recommended or very productive.

Like this: https://code.visualstudio.com/api/get-started/your-first-ext...

Yeah I have no idea why they still, after all this time, can’t get melpa to run out of the box.

In 20 years and you don't know, sounds unbelievable. I don't know what you mean, it is so easy and works:

M-x list-packages

Choose a package and install. It is all well integrated.

YMMV, out of hundreds emacs packages I use, I remember issues installing exactly one package. For comparison, I easily remember issues with more than deb package on Ubuntu and I consider apt-get ecosystem as pretty reliable.

How and what do you use for package management on emacs?

Mostly use-package for configuring and installing (as far as I know it uses builtin package-install)

    (use-package which-key
      :config
      (which-key-mode))

https://github.com/jwiegley/use-package#use-package-ensure-s...

Historically, el-get e.g.:

  (el-get-bundle ace-link)

https://github.com/dimitri/el-get#el-get-elpa-and-packageel

Though it's made great improvements in recent years, GNU Emacs, the vanilla package, is more of an unrefined platform than a more finalized product that competitors like VSCode are.

SpaceEmacs is closer to such a refined product, though it's aimed at Vim users (with the 'evil' Vim-support package being front and foremost). I am not currently aware of a kind of "best-of-emacs" distribution that focuses on putting Emacs' strengths in their best light (likely at the cost of dropping some UI backwards-compatibility).

As an aside, the article [1] by Dan Coliascione (@quotemstr) from a few years ago about the effort required to work with Emacs' compatibility layers is insightful and hilarious. "GNU Emacs is an old-school C program emulating a 1980s Symbolics Lisp Machine emulating an old-fashioned Motif-style Xt toolkit emulating a 1970s text terminal emulating a 1960s teletype."

I honestly don't expect vanilla GNU Emacs to modernize its UI, because of its incredible legacy baggage. But I do look forward to new "distributions" that do so!

https://www.facebook.com/notes/daniel-colascione/buttery-smo...

https://github.com/bbatsov/prelude

Thanks! I had forgotten about Emacs Prelude.

Wow, that's the same guy who made Rubocop. That's neat!

Doom Emacs is much more polished than Spacemacs, and yet lighter weight.

But Doom Emacs presents itself as:

"Doom is a configuration framework for GNU Emacs tailored for Emacs bankruptcy veterans who want less framework in their frameworks, a modicum of stability (and reproducibility) from their package manager, and the performance of a hand rolled config (or better). It can be a foundation for your own config or a resource for Emacs enthusiasts to learn more about our favorite operating system."

I haven't tried it myself, but it doesn't sound like a packaged distribution, more of a framework, no?

Ignore that, it's just bad marketing. Doom is a packaged distribution and it's waaaaay better than Spacemacs (and much easier to modify). Spacemacs is a very poorly written piece of software in comparison. Doom is moving much faster as a result.

I love this: “Or, as Richard Stallman put it”: ‘It is unfortunate that the people who implemented the newer editors chose incompatibility with Emacs.’

It is interesting to see a comment that is 100% at odds with the brutal evolution of ideas that occurs in a good ecology of software.

If the same mindset applies to the rest of emacs then they really stand no chance or real progress. (edit: the rest of emacs, and not just key bindings which the RMS quote I have removed from context applies to).

I suppose rms can't understand why anybody would think anything could be better than what he chose to do 40-something years ago.

A lot of things are different without being better.

Before ctrl-x/Ctrl-v became the standard for Cut/paste, it was Ctrl-del/Ctrl-insert in many dos and early Windows editors - which makes a lot more mnemonic sense.

It’s better to standardize on something, but that something isn’t necessarily better and is often worse.

Those might make more sense, but even if my MacBook had Insert & Del keys, I doubt I could Ctrl- them with one hand.

C-x and C-c make some sense as cut and copy. But C-v, C-z, C-y as paste, undo, and redo just make little sense. The first two make sense for their proximity to x and c in the QWERTY layout. y only makes sense if it happened to be unassigned.

Keyboard shortcuts will always fall into one of two categories: That makes perfect sense (usually mapping to a mnemonic like C-a for "select all"); That's totally arbitrary (C-y). It makes sense (and cua-mode offers it) to offer the opportunity to rebind the keys to the mainstream arbitrarily selected shortcuts, but it also makes sense to keep what's been used by emacs users for 40 years since that's what they're used to at this point (oh hell, I've been using it for 20 years, time has flown).

Mnemonic keyboard shortcuts must be a bastard to learn if you don’t speak English.

And shortcuts based on finger distance must suck for anyone using a non-qwerty keyboard (especially a non-latin character based language!).

Indeed. I use the Dvorak layout (a choice I made twenty years ago and have stuck with since my typing speed did improve, by virtue of finally learning to touch type properly), and many shortcuts make no sense. On the other hand, I actually found emacs much more comfortable to use.

The P and V operations on semaphores are from Dutch. I find this difficult, "The V kind of looks like a down arrow.. but wait no that's increment. The P could mean plus.. wait no that's decrement..."

A third category is those chosen for their physical position.

Note that redo is often ctrl+shift+z which is much easier to type. However redo is a weird case because traditionally most GUI applications (at least on Windows) didn't have explicit redo even until late 90s/early 2000s and redo was just undo a second time (ie. undo was just a flip between the last and previous state). When applications started to add an undo stack and redo command there wasn't a commonly accepted shortcut key for it so they used whatever made sense for the developers - which is how ctrl+y (previous to letter z) and ctrl+shift+z (in Windows shift often inverts the action, e.g. alt+tab vs alt+shift+tab) came to be (though those weren't the only ones).

FWIW it was Shift+Del for Cut, Shift+Insert for Paste and Ctrl+Insert for Copy and AFAIK that came from IBM's CUA. Also these shortcuts are still supported by Windows (and personally while i use Ctrl+X and Ctrl+C for Cut and Copy, i tend to use Shift+Insert for Paste :-P).

Ctrl+Ins for copy, Shift+Del for cut and Shift+Ins for paste. Still works in Windows. Ctrl+Del deletes a word.

DOS editors often used WordStar bindings. C-k C-b to start a block, C-k C-c to copy or C-k C-v to move. Turbo Pascal used these bindings. They're also the default bindings for the `joe` editor.

And Ctrl+Ins, Shift+Del, Shift+Ins work out of the box in (windowed) Emacs, too.

ctrl x/c/v is best because you can do it with your left hand while your right hand is using the mouse.

Yes! Exactly!

Yes, what really pisses me off about emacs is the mind-numbing arrogance - they're basically saying "people ought not to have broke from our button scheme, so we'll just ignore it to our users' detriment!".

There's this implicit argument that convention is some sort of monarchist hierarchy where the successor mustbenamed as heir first, and what convention is most common is somehow irrelevant. It's infuriating.

Emacs has lasted 40 years with a stable (but small) market share. It's outlived every other editor with the exception of Vim. It will probably outlive Atom, and it looks like it's going to outlive Netbeans.

I'd argue stubborn resistance to most new concepts regardless of their sheen is a contributor. I think people underrate that as a trait. You want some bastions. Loads of it is insane but they also don't make many new mistakes.

That isn't Emacs, that's Stallman, who is known to be stubborn.

It already caused a major fork, XEmacs, which used to be important, I suppose, but a combination of GNU Emacs catching up with the features XEmacs people wanted and XEmacs simply sputtering out has made GNU Emacs the last full Emacs standing again.

I don't think so. Emacs developers are quite friendly and accept opinions and advices of anybody, feel free to write to developers: https://lists.gnu.org/archive/html/emacs-devel/

The only version of Emacs I ever used regularly was (Lucid|X)emacs. According to folks on the Lucid side working with RMS was difficult[1] to say the least. In the end, Xemacs lost traction (and development) and I moved on from Emacs, it just didn't suit how I wanted to work well.

Emacs has the developers to correct the problems but they need to let go over a 40 year old vision and evolve a bit.

[1] https://www.jwz.org/doc/lemacs.html - Of course, this is biased towards to Lucid side of the story. But I remember following this.

Do the defaults in Emacs matter, at all? Doom Emacs, Spacemacs, and dozens of other default configs already exist. I've been using Emacs for years, I never learned the default keybindings. I used Evil mode right from the start.

I just don't see this as a real problem.

A small (incomplete) list of real problems:

- No timeline on Wayland support, Wayland will likely require substantial work and refactoring.

- Performance issues on long lines of text.

- Architectural/technical debt.

- etc...

Emacs is, fundamentally, a power-user editor. There are problems to solve, but "I had to change the default fonts" isn't one of them. Why would you use Emacs in the first place if you weren't interested in changing the default fonts? Maybe I'm out of touch, but I would never recommend a new Emacs user to just download Emacs directly. I assume they're starting with someone else's config.

Emacs fills a specific niche that other text editors today still aren't satisfying, and it should continue to fill that niche. What other text editor can I use as a window manager?

I haven't checked in a while, but I think Spacemacs solves literally every single problem that they're talking about, including prompting users whether they'd like to enable CUA mode by default. But Spacemacs can't solve the Wayland problem.

That was touched on in the article:

> Some of the ideas found in these distributions may well merit inclusion in Emacs, but that does not happen. Emacs maintainer Eli Zaretskii complained that the creators of these distributions do not contribute their work back.

If the changes aren't being contributed back, any gain from them is lost for users of the default system. Creating an unnecessary fork within the user base, especially where the changes could be enabled via a configuration change (start with default, but prompt at first run to go to Doom Emacs or Spacemacs).

The article also touched on why this is the case: Not everyone wants to assign copyright to the FSF.

> Some of the ideas found in these distributions may well merit inclusion in Emacs, but that does not happen.

Spacemacs isn't an Emacs fork, it's a set of packages and configuration files that are provided transparently on top of an existing Emacs install.

It's not necessary (or desirable) to include Evil mode out of the box for bare-bones Emacs installs, and for the most part, new users shouldn't be using bare-bones Emacs installs. It's not important that Emacs be an amazing experience with fantastic defaults out-of-the-box.

This is like arguing that Linux is outdated because Gnome isn't built into the kernel. New users download a distro based on Linux, like Ubuntu. That's fine, it's not a problem that needs to be solved.

In the same way, new Emacs users download "distros" that include secondary packages like Evil mode. That is also fine, it's not a problem that needs to be solved.

> Emacs maintainer Eli Zaretskii complained that the creators of these distributions do not contribute their work back.

Even assuming that we would want to merge Spacemacs changes into the core Emacs codebase (which we don't), I still have zero sympathy on this point.

All of these downstream projects are Open Source -- they are contributing their work back. If the FSF refuses to merge compatible, Open Source code back into the Emacs codebase without developers signing away their ownership, that's the FSF's problem, not the downstream developer's.

I thought the whole point of Open Source licensing was that people didn't need to own the code to use it. Being a good Open Source community member is not conditional on anybody giving ownership of their code to the FSF, it is conditional on releasing that code under Open, compatible licenses.

I'm not convinced there's a lot from Doom/Spacemacs that could reasonably be contributed back to Emacs. It's mostly installing and configuring other packages to have a nice default setup.

Perhaps the startup speed tweaks provided by Doom, could be enabled by default. I have seen the concept of modules implemented in a few different distributions, as well as in some users configuration. Perhaps a built-in module system would be beneficial. Doom has a deterministic package management system.

Don't forget syntax highlighting shortcomings. Sublime, VS Code, Syntect, Pygments, and other highlighting engines all get most languages right. Emacs and vim both do weak and incomplete jobs identifying tokens. It makes nice color schemes look bland because they skew toward only a few colors. At least neovim is working on treesitting which should improve this ability.

Right, I've noticed this while trying to update my vimrc for web development. Syntax highlighting is just not as nice as in vscode.

Wayland support is actually being actively worked on. It is done via "native" (no X widgets) GTK support. You can find it on: https://github.com/masm11/emacs

The plan is to get that merged upstream at some point, you can find out more about it on the official mailing lists.

Oh thank you for the link, I've had to discard emacs when I've switched to sway/wayland and I can't wait finally having emacs available for my muscle memory. Magit changed my life

The GTK fork is great, but it’s so slow - especially on HiDPI displays.

I tried it out on my 4K monitor and I felt a noticeable increase in typing latency. It started to feel a lot more like VS Code.

Ultimately I was about to get HiDPI support working in Xwayland in Sway with a series of patches and I ran Lucid Emacs, which was much faster and made the latency increase go away entirely.

The Emacs community should start by perfecting lsp-mode so that it can compete with VS Code in terms of functionality. That will simultaneously keep power users from switching AND bring in people from other "easy to use" editors that lack such functionality.

Emacs needs this so bad but I really believe it could never attract enough people to develop and maintain it without sane defaults.

I find that lsp-mode works pretty well most of the time. If you look at the commit history, the project is very active. It's also pretty easy to set up.

I found that it didn't work out of the box for me (Rust and Python) but that eglot did work out of the box.

Eglot, not lsp-mode, will be the LSP implementation that makes it into the GNU Emacs distribution (because it is being developed with FSF assignments, and because the maintainer is active in the GNU Emacs development community, maintaining eldoc and flymake, and maybe others).

It would be bad if it did, IMO. Eglot is a pretty dodgy piece of software and the code is much worse than lsp-mode.

Could you give some justification for that criticism and assertion please? (On its own, your comment falls short of HN standards.)

Sure, here are some samples from the source.

This is Eglot's code. Try and figure out what's happening in each of these passages:

https://github.com/joaotavora/eglot/blob/master/eglot.el#L41...

https://github.com/joaotavora/eglot/blob/master/eglot.el#L17...

Contrast with lsp-mode:

https://github.com/emacs-lsp/lsp-mode/blob/master/lsp-mode.e...

https://github.com/emacs-lsp/lsp-mode/blob/master/lsp-modeli...

The lsp-mode code is a lot easier to follow, in my opinion. It's a lot clearer what's happening (although I can't say much about whether either are overabstracted which is admittedly a big concern. I haven't looked into that).

I remember watching an argument between the original authors on Reddit a while back. The lsp-mode author came across as... let's just say more professional. lsp-mode seems much closer to a professional product to me in general.

Also it's low resolution, but note the issues ratio.

Eglot: 70 open, 277 closed

lsp-mode: 94 open, 977 closed

(lsp-mode is much more than 3x the size of eglot and has 15x the number of downloads on MELPA)

Thanks. It's true that the eglot code is hard to understand (and based on your links I suspecter hard_er_). I had been provisionally assuming that that was because the author is a much more advanced lisp programmer than me (which is true; I'm fairly sure he's one of those emacs developers that is also an experienced common lisp developer).

In any case, I would prefer that neither become part of GNU Emacs since then the development process and code review will become completely opaque (I'm not sure code review is really a thing once it's in Emacs. Just maintainers with push rights to some repo on savannah or something)

I basically gave up on Emacs and switched to a combination of VS Code and old-school vi for Go and everything else, respectively. Finding an effing theme that allowed me to program in Go in a terminal without making LSP’s overlays unreadable was nearly impossible. I spent days trying to make this work. I’ve used Emacs since 1991.

This is possible, but it's a bit of a pain. One problem is that the popular themes cater to GUI Emacs users where you have 24-bit color depth. On the terminal this gets approximated to one of the available 256 colors, and this approximation is often not great. This makes themes on the terminal look weird sometimes.

With some work, you can enable 24-bit color support in TTY emacs, which solves this problem. Combine this with some work to either tweak or remove the more obnoxious LSP overlays and you can have a fairly good LSP experience on the TTY.

I wanted a monochrome terminal but was willing to tolerate traditional ANSI color. Once you start with 24 bit color you may as well start using a VNC client.

What sapped my will to live was the impossibility of doing a C-u C-x = on the overlays to determine how their contents were styled, forcing me to go into the source code of a ton of different packages to go fishing for face names to coerce to visible values.

Yes it’s possible but it’s insane. Emacs carries around all of this terminal baggage but many module developers seem to have forgotten about terminal users. Additionally, theming is conceptually broken in that it creates an MxN problem with themes and modes’ face names. This could be solved if modes stopped with the proliferation of mode-specific face names but good luck with that.

Is the LSP architecture the way to go, though? In my experience it's quite a bit slower than built in emacs modes. I can't use tools that are slower than me.

Are you on Emacs 27 yet? Below that Emacs encodes JSON in Elisp, which is extremely slow and makes LSP unusable.

Upgrading to 27 made no difference for me.

In that case something dramatic is eclipsing it, it should be noticeable. It may be the GC threshold. There's about 5 settings recommended for perf issues.

https://emacs-lsp.github.io/lsp-mode/page/performance/

Ordinarily I'd ignore rabbit holes like this but LSP is unusually useful. It's worth a shot.

I've done all of that. Still slow. I think the problem is other people have lower standards than I do when it comes to speed.

There's a command called M-x lsp-doctor that will tell you if you meet all the performance requirements for LSP mode. Among those is emacs 27 compiled with native json support (you can build emacs 27 without native json).

Maybe, but at the same time it seems like the best option for general language support in emacs.

A lot of languages have working lsp implementations (at least according to https://langserver.org/) and, assuming it will stick around, this means that emacs can get all of these nice features "for free" by having an lsp implementation. This is a much safer bet than just assuming that somebody will provide and maintain emacs plugins for <insert language x here> that provide everything that lsp would.

I'm going to approach this as a pure social thing.

To me emacs fits in a way because it fits the kinda misfit/hacker mentality I had back when I started playing with computers/software.

I found emacs and linux as the coolest things in the world while everyone was thinking computers were somehow for unwanted geeks in a basement.

And honestly that did not feel me with a need to be cool, wanted or popular.

Instead I developed a sense that having to learn things the hard way, fail and continue until I got it right without regard to what others thought had a super high value.

And to me that's what emacs symbolizes, it doesn't need to be popular or cool and maybe it will die at some point but even if that would be unfortunate it will have been central to a generation of free thinking, intelligent programmers.

And now it's 2020 it's cool to be a programmer, and we're awash with learn to be a dev the easy way seminars and here's how you can deploy your app in 2 clicks...

And that's good but it doesn't mean emacs has to be that way.

I think it is way way easier instead to create a new editor with the same free software mentality. Maybe that's Theia under the Eclipse Foundation, maybe it's something else. But migrating emacs to a VSCode like popular idea is crazy, you just can't migrate all of that.

Full disclosure I worked on GDB (using emacs) and Theia (a vscode like editor) and used emacs for 15+ years mainly doing c/cpp and org mode.

I'm surprised by this .. emacs have seen so much activity on so many layers. From cute transient overlays, lsp, deeply critical modes (magit), and even deep level work. The community is sharing a lot of extensions of all kinds through melpa and similar. I don't think emacs have been as 'popular' as now since long ago.

Also one consideration, emacs is still lean, all those others editors are html/js based and hyper heavy.

Funny that Emacs is considered “lean” today. It was definitely consider one of the heaviest, most bloated editors out there in the past. “Eight Megabytes And Constantly Swapping”

Indeed but the swap is real, I tried vscode (win64) on a 2nd gen i5 and couldn't insert chars in real time. Emacs is not smooth on windows but I couldn't go back to it fast enough.

Seriously! In my early Linux days (before 1994) I wouldn't run emacs. My first serious Linux system (486) had 8 megs of RAM and running emacs would bring things to a halt. I upgraded it to 32 megs which was amazing for the time...

The article did point it out. It likely has more users than it ever has - just that the growth is slow, and it has dropped in terms of percentage use.

but the market share war is absurd, nothing of quality came out of this

Yeah, to an extent I agree. If you're just using your text editor as a text editor—and you're willing to have fairly limited support for integrations and other stuff like that—worrying about market share is unnecessary. If you rely on complex, IDE-type features for languages that move quickly, you might be better-served by a more popular editor.

As a computer scientist since 1979[1], Emacs and vi both are across my working life. Teco died. The many alternate modal editors, ed aside, mostly were fringe.

I tended to the vi side but I deliberately shifted back to Emacs for org mode and to keep my brain agile. The psychological cost of shifting is contained in "six weeks to relearn a habit" which in a lifetime is acceptable cost.

The outer gui emacs is dead to me: I'm not seeking more mice in my life, if I was i would have gone to Rob Pike's work.

the ascii gui menu bar being disabled now, melpa and elpa giving me just enough, I think Emacs can start chasing finer grained revision numbering. There does not need to be an Emacs 30+.

Vi peaked in nvi from Keith Bostic. Vim is really its own thing now. I prefer nvi.

Emacs had more variants [2] but they died on the vine and now its Emacs, xemacs, and spacemacs for odd people[3].

[1] in Hypothesis: I graduated in 1982 but you learn editor in first year... so...

[2] Gosling did a good one. Small, fast. I used this a lot in 1984. The macro repeat mode did some good stuff without needing lisp. It's because he did this i am charitable about Java.

[3] just choose Emacs or vi for goodness sake!

Yeah definitely ignore all the seasonal requests for the latest fads, and just focus on the last paragraph. I think the post author agrees, hence the sarcastic tone.

The fact is Emacs does many neat things but is also a giant steaming pile of sh-- tech debt. I'm sure VSCode will get there too as time passes, but older editors simply have a head start in this regard.

Emacs needs it's Neovim (which also contributes back to Vim) moment. My old favorite would be returning to https://www.emacswiki.org/emacs/GuileEmacs and finishing that off. No reason Emacs needs to also maintain it's own Lisp engine, and I'm sure lexical scope would help reign in tech debt too.

Oh, and make emacsclient to a eamcsserver on another machine work, please! That would be such a killer app.

emacsclient to an emacsserver on another machine works fine. You'll want to tunnel it over ssh.

If the machines don't have a shared filesystem namespace, I suggest writing a small wrapper that translates the file's pathname to what the server needs (whether that's a mounted network filesystem or a tramp string or whatever).

> emacsclient to an emacsserver on another machine works fine. You'll want to tunnel it over ssh.

Yeah after a bunch of dumb stackoverflows said it was impossible because it uses a unix domain socket (eyeroll), I tried that.

> If the machines don't have a shared filesystem namespace, I suggest writing a small wrapper that translates the file's pathname to what the server needs (whether that's a mounted network filesystem or a tramp string or whatever).

Err but I don't want to try to align the file systems at all. I want the server to do all the work so the client is just doing human<->computer IO.

I would love something like “Emacs’s Neovim”. Guile should be enough. Keep packages out of the global namespace. Get rid of Elisp and all its differences. Let me use C-Z/X/C/V for undo/cut/copy/paste (or maybe C-Shift-C is fine?)

Keep org-mode, web-mode, etc :-)

I don't think we even need Guile (though I wouldn't complain). Just cleaning up the way packages install (a proper package system, which could be optional) would be a vast improvement for elisp.

By creating a package system, making everything default into the el-user package if not otherwise specified, and moving the core elisp capabilities to the el/emacs-lisp package (used by el-user, importing everything), you'd create a clean path for moving forward. I have zero time and energy to contribute to emacs, but this is really the only fundamental change I'd want as someone who does delve into elisp frequently (or used to, not so much in the past year or so).

Personally, I would love Guile. There are just so many quirks to Elisp, and Scheme is more “known”.

Yes this 100%. My son is just finishing high school and is taking an interest in code to the level of questioning if it’s worth learning emacs/vim. At the time I spoke of how emacs seems to be approaching a neovim moment and then pointed out that practically if the community was not prepared to invest in supporting new users like him, then he’s better off not supporting them and to look solidly at neovim (beyond the default of vscode).

As I see it the older emacs users see many of their decisions as right because they made them. What I’m sensing is a total lack of basic design thinking. A “neoEmacs” could achieve this, get clear who the new target audience is and based around this what a neoEmacs clear project goals would be (something like “position an emacs to be the editor of choice for people born after the year 2000”) [or whatever] and then with a new persona start to unpack critical design considerations and priorities a project plan from there.

For emacs to survive/thrive it will need to go through a process of transformation. Even from these conversations I can see right now that can’t happen with the current core emacs project. I neoEmacs would be a great way forward.

Not saying this is the way to do it but there is a remacs which is working on rewriting Emacs in Rust and fixing the C level issues in the process: https://github.com/remacs/remacs

I always wonder how those "dark mode" or "change menu" requestors would react to the interfaces of airplanes or helicopters. People want complex and powerful tools to look like a car with an automatic gear or even a bicycle. Yes, the learning curve to fly is steeper than the learning curve to drive. As is the learning curve to drive with stick gear instead of automatic.

But you do not need to learn all the intracies of emacs to use it effectively. My wife (non IT) is quite capable of using Aquamacs on a Mac to do her editing. And using org-mode. She switched to Aquamacs after living twice through the harsh experience of Apple killing various programs and leaving her with proprietary document formats she needed to somehow convert/recover to the next "cool" word processor.

I got into contact with emacs (actually zmacs) on Lisp machines long ago. And it had some very nice features which I still miss in the classic emacs. But they vanished due to "worse is better" as did the wonderful space cadet keyboard.

Glad to see that other observers have keyed in on the discoverability aspect. I tried to highlight it in [1]. Unfortunately I haven't been able to hop back into the discussion there, and things have been moving at a fantastic pace.

The longer I have been working to develop processes and systems, the more I have come to appreciate defaults that do not change. It is interesting to see some of the new *coin and blockchain folks in their dark forest threads worrying about what happens if the interpreter changes its semantics and lamenting that contracts are meaningless if the interpreter can change. That is what standards are for, and that is what the "backwards geezers" are trying to do for Emacs since it doesn't have a standard, only social norms. I'm not too too worried though, since there are many sensible people in the community who understand why changing defaults can destroy trust and waste the time of millions of people. I am also not worried because there are many creative solutions to the problem of how to attract and maintain new users in a way that they can come to appreciate the benefits of stability.

1. https://lists.gnu.org/archive/html/emacs-devel/2020-09/msg00...

Changing the default UI is a non-problem: new users will like it, old-timers will have an easy time reverting it, or maybe their custom config will undo it right away, depending how it is implemented. Source: I am actually a Vim user, which under Windows comes with some Windows shortcuts by default. I had no problem undoing it.

The idea of copying current UI trends (dark theme, burger menu) however made me think of that quote saying that the best way to anticipate the future is to invent it.

By imitating others you are not modern, you already are behind.

Doing the same thing but only slightly better won't attract much users - Emacs should have learned that from its victories against its clones. Doing something different for the sake of being different won't attract much users either. The challenge - and the opportunity - is to do things differently in order to make something significantly better (vim cough vim).

I have been an Emacs user for 20+ years, and I don't use editors that can't be configured to use Emacs key bindings. Luckily IDEs like Visual Studio can be configured to mimic Emacs.

To me the issues that make Emacs not modern are: (1) Slow startup. (2) Buggy language modes. (The ones that come with it are good, but third party ones such as web-mode are buggy.) and (3) No intellisense out of the box.

For the first point, use emacs service + emacsclient. Starts instantly.

This and avoiding require in your .emacs. When packages are autoloaded on demand emacs starts up quickly. As a quick test try emacs -q” to see if something in your .emacs is the cause of the slowdown.

To add to this excellent point; a common culprit is not using ~use-package~ correctly to lazy-load as much as you can. I use Emacs extensively for all my languages and have loads of packages installed, but the startup time is around half-a-second on a newish Ryzen laptop running Nix from a cold restart.

It is not that slow. On my machine Vanilla Emacs starts in 0.1 second. With my 12 years-old config, it starts in 0.4 second. Emacs 27 pre-init system made it even faster.

And if your machine is slow you can use a daemon.

Emacs is really fun.

Edit files remotely: `/ssh:bird@bastion:/path`

Edit files two hops away: `/ssh:bird@bastion|ssh:you@remotehost:/path`

Edit files two hops away, also in a docker container: `/ssh:bird@bastion|ssh:you@remotehost|docker:container:/path`

oh, I have used ange-ftp to edit remote files in the days such functionality was not upstream (and nobody considered ftp being dangerous...) But I missed that it supports docker. Not that I particularly like docker, it's ActiveX, use random executable code from unknown sources and give it too many privileges all again, but sometimes I use it.

Emacs needs a package manager that is as easy to use as the one that comes with VS Code.

The plugins are the reason VS Code is popular. It's so, so easy to discover them and install them. You can download VS code and have a working dev environment with autocomplete and a debugger for almost any major programming language in 10 minutes.

When I started working in the tech industry, Textmate was pretty popular. It was supplanted by Sublime Text, which was supplanted by VS Code. Each time, the main factor in getting people to switch was the ease of finding and installing plugins.

As of today, there are 4 721 packages for Emacs on MELPA (https://melpa.org/#/). The setup to use it are a couple of lines in the config file.

However, users have to first know it's an option to use. Why not add it by default, and even have a menu option to install package? VSCode will even recommend popular packages depending on file types you load.

Because it's not core emacs. Core emacs uses ELPA, which has fewer packages.

Don’t you see why that’s a problem? Multiple package managers, with none enabled out of the box, and poor usability?

It's not multiple packages managers, but different sources for packages.

And elpa is enabled out of the box ;-)

I’ve recently switched to VS Code, and the driving issue for me was really related to the popularity of the editor. Some combination of the LSP server and the chain of emacs packages to interface with that server were constantly broken. I can’t blame the maintainers, seeing as the LSP was being implemented by a skeleton crew and the various emacs packages were abandoned short of a couple heroes fixing some of the big bugs.

I still miss things like Magit, the binds from Spacemacs, the project integration from Projectile and Ivy/Helm, and more. VS Code has some other pluses too though, like a better terminal and smooth rendering / performance. I don’t see emacs getting those features without more popularity, but I hope VS Code gets the things I miss given how many people use it.

I _highly_ recommend emacs-libvterm. Without a doubt, it's an advanced install, so I'm not arguing its better for beginners, but I adore it just the same.

https://github.com/akermu/emacs-libvterm

That’s a promising project. Evil integration is a key feature for me, but once that is supported that will be a killer package.

> many (young) people seem to spend most of their time watching videos (as in, watching videos is their equivalent to my being idle). But admittedly, those videos usually last 10s or so (and if not, they switch to the next video anyway), so we'd have to use very short videos, ideally funny and sexy, maybe with a cat?

If I ever say anything like this in a UX discussion, please just shoot me that instant. This person's arrogance makes me shiver.

"Some of the ideas found in these distributions may well merit inclusion in Emacs, but that does not happen."

1. Which ideas are they referring to exactly? Can't upstream something if you don't know what they want...

2. How do you even get approved to send code to FSF owned projects? I read somewhere you need to send a copy of your employment contract for them to determine you can assign copyright to them. But what are the exact steps? Who do you email? How do you exactly encrypt the file? What are the acceptance/rejection criteria? No seriously, somebody please make a beginners tutorial about this, I have no idea how to start.

3. Upstream Emacs releases once a couple of years or more, with no predictable schedule, can't blame anybody for wanting to stay away from upstream and have their setup under their control. But then again, I know of a worse offender...

So... what should my next steps be?

There’s a healthy Emacs community on Reddit (r/emacs) where you can find answers to these questions and more, if you prefer that to the Emacs mailing list (which is the definitive place for such questions).

From what I’ve seen, folks on the mailing list do generally welcome & encourage contributions upstream (Stallman, especially) but it does sometimes take a little more effort to convince people about the value of a new feature/package, and then iterate on a solution so that it doesn’t break decades of accumulated use cases (the perils of success).

> There was some discussion of adopting the Solarized color palette in particular. As Dmitry Gutov pointed out, though, Solarized makes for a rather low-contrast experience

This is a strange complaint - it's tautological. The whole point of Solarized is to reduce the contrast.[1] It's kind of like saying having a dark background is bad, because it is dark.

For people who stare at a computer all day, a lower contrast is good. When I introduced it to a coworker, he didn't want to switch to it because of the low contrast. After a week of using it, he can't imagine going back to high contrast.

As for the rest, while I do agree with some points, I will say: If you make Emacs more like VS Code, then people will have even fewer reasons to use Emacs.

[1] https://ethanschoonover.com/solarized/

It's an accessibility issue. Low contrast sucks for people with vision issues. dark mode can be kinda sucky too. Not that the default modes of most editors are much better. I'm color blind and have never really found a totally satisfactory scheme.

The point isn't to reduce the contrast, it's to use contrast based on hue and less on value.

Accessibility is the real concern. Solarized fails many of the checks for accessible text under standards such as WCAG 2.0.

> The point isn't to reduce the contrast, it's to use contrast based on hue instead of value.

It's not one or the other. It's both:

> Solarized reduces brightness contrast but, unlike many low contrast colorschemes, retains contrasting hues

Hue contrast is objectively worse than brightness contrast because human cone cells are lower resolution than rod cells. This is the reason chroma subsampling is used in lossy video/image compression.

> For people who stare at a computer all day, a lower contrast is good.

I stare at a computer all day and I hate low contrast themes, including solarized.

I am not claiming my view applies to everyone, so please, could you stop doing that. It is subjective: there is nothing inherently superior about solarized, even for people who stare at screens all day.

And it is not just an accessibility issue. It is a subjectivity issue.

There is surprisingly little research on this.

Personally I find that contrast between different themes, that is when switching from say one website to another, is the most eye strain inducing. Going from reading black on white to white on black or vice versa just hurts.

I keep everything black/dark on white themed since that's how most of the world works. I suspect many who use certain themes experience eye strain when viewing normal stuff and falsely assume it proves the efficacy of their theme.

To each his own - there are many choices, easily installed:

https://emacsthemes.com/

This really doesn't seem that complicated.

(1) Either we aim to make Emacs popular or we don't.

Personally, I don't think we should bother: I suggest we make it a razor-sharp tool for people prepared to learn some lisp. I also suggest we open up the development experience to allow contributions and code review via PRs.

But lots of people want to make it popular. So fine, we do that. Then there's no argument at all for keeping the defaults like a bunch of male lisp programmers over the age of 50 want. Because every single one of them has an emacs init file they've been tending to for decades and they know how to make the relevant changes to override the defaults.

So if we are making it popular there should be no time whatsoever given to RMS saying that some keybinding from the early 80s is objectively better.

It's hard for me to imagine a world in which the Emacs core team has much to do with the look-and-feel of the Emacs that gets new users to adopt it. Haven't Spacemacs and Doom have done more to recruit Emacs users than anything the core team has done in a decade? Maybe "dark theme" and "lots of menus" aren't the problems the core team should be worrying about; leave that to other projects?

The idea that what Emacs needs is more or differently organized menus is pretty funny though. Maybe if we could just get all the customize groups into a single tree view it would all make sense to people!

What Emacs needs is a better, clearner, more complete "standard library" and a better package and dependency management system both for applications and libraries. Sure MELPA is nice, and I use it a lot, but I do think there is room for improvement.

It also needs a better way to manage configuration both personal/local and collaboratively maintained ways of configuring the editor.

It needs "good idiomatic everything". Right now it is "half-assed everything". And while someone might take that as an insult, it isn't meant as one. It is meant as how I, someone who has used Emacs for 30+ years and still use it to write all my code, see Emacs. Every few years I try to update my Emacs setup (it is too painful to mess with regularly) and as I have less and less time to spend on this task, my Emacs setup isn't as functional as it used to be.

Which makes it more and more tempting to switch to an IDE. I want to write code. Not spend my afternoon Googling solutions to problems and trying to decide which solution will damage my current setup the least.

As for whether or not it needs a better Lisp implementation I can't really judge since I haven't written any Emacs extensions for nearly two decades. Nor would I say I am a sufficiently competent Lisp programmer to make that judgement.

Does Emacs need a new Lisp?

I think focus needs to be on how you can get Emacs to where it feels accessible and usable to a larger population of developers. Right now it has high barriers of entry and it doesn't feel like there is any obvious path to developing and distributing libraries, extensions and applications.

Compare this to VSCode which owes its success to Microsoft being able to leverage lots and lots of developers who feel at home. Yes, this is to a large degree because it is based on a more popular language, but also because the community around VSCode is bigger, produces more documentation, can provide more help, and is in general more approachable. Now you may like or dislike VSCode, but there is no denying that it is more successful in attracting developers than Emacs is.

(Note that I'm not interested in Dark Mode or cosmetics. That comes later)

> It is unfortunate that the people who implemented the newer editors chose incompatibility with Emacs.

As always Stallman maintains a ludicrous level of self importance.

Emacs has been my editor of choice, but I've been changing my preferences.

Some pros:

You can be sure that this editor will still be available 30 years from now, and that by learning it today, that knowledge won't become irrelevant.

It's easily the most efficient editor at editing text, the things it does for editing text, it does to near perfection, starting from seemingly simple things, like an undo functionality that can always get you back to a previous state, or that can operate only on a region.

It's also programmable to an extent that more modern editors aren't. Its programmable environment is always there, you can always evaluate a function and have it available, you don't need to build an add-on with special packaging, like you must in other editors.

---

Cons:

It's a constant pain in the ass. Whenever something ain't working, you end up going into a rabbit hole, only to emerge hours, or days later with a broken solution and a bruised self-esteem. It's really that bad.

If you have a working configuration, it was probably tuned during the last decade at the very least. And the cycle of yak shaving and self loathing repeats itself whenever you add new packages. People treat their Emacs configuration file as a lifelong project, keeping it in a public version control, because it would be a disaster losing it.

By contrast, VS Code and its packages, even when less featureful, tend to work out of the box, and that's a very big deal. Most people don't save their configuration, because they really don't need to, starting again from scratch isn't that big of a deal.

Emacs might be super programmable, old extensions might be great, but, as a trend, new extensions developed are of worse quality than extensions developed for other editors, for the same functionality. For example LSP, and language packages that depend on LSP. The reason for why that happens is unclear to me, maybe it's an indication that the APIs are more fragile, or maybe it's a reflection of its fading popularity.

It's kind of like (GNU) Linux in a way, the same culture of not giving a shit about regular users, if you want to use this thing you have to earn it, by going through a decade of suffering.

If we want to attract more newcomers, I vote we use video.

The emacs welcome screen should link (and encourage) a youtube playlist (or some video hosted somewhere, if a commercial site is undesirable - or even play right there in the editor) that introduces the editor with, say, a dozen very short introductory videos, well-produced with an enthusiastic voice-over demonstrator. Eventually these can be translated so one can watch in their local language.

The pitch of "it's a musical instrument, you have to first practice and then greatness will come" needs to be in the first video, with the promise that the videos will quickly get to a tour of that greatness. Then cover some beginner basics. Maybe don't mention lisp in the first video.

And then in the following videos, quickly get to magit, org-mode, LSP/slime/cider, yasnippet, and other pizzazz while keeping it practical.

(This probably even exists somewhere?)

Finally, there is a lot of reading material on the welcome screen, but it should include a chat location to get advice from volunteers who don't mind a relentless stream of "how do I copy and paste" introductory questions and will answer them enthusiastically. If it's IRC, that's fine, but it would be best if just clicking in the browser launched an IRC client and took you there, either in-editor or on gnu.org as a web widget or something (like guix has).

I'd also reverse the existing stanzas in the welcome screen: "Emacs Tutorial..." first, "GNU and Freedom..." next, and "Author..." third. It's more practical that way.

Emacs has a lot of cruft on the code-level. The worst part is the lack of separation between "backend" and "frontend".

There is support for many different "frontend" architectures: Win32/MacOS/Gtk/<Motif and many more old X11 toolkits>

But a lot of code was just duplicated when a new frontend architecture was added. And started to grow into different directions. The code is littered with #ifdef and there is no clear API for the fronted architectures to sit on top of.

For example, font handling is different for most frontends. And this difference leaks into the core part of Emacs where line-breaks are managed, etc.

There is work towards a "pure GTK" that uses Cairo as a drawing surface.

https://github.com/masm11/emacs

Imho the Cairo "drawing surface" and font handling should be the only implementation for what it does and reused for all frontend architectures. With the exception of terminal sessions...

But, Emacs devs are very conservative when it comes to "modernize". In my experience, it is a lot easier to add stuff than to clean up. That also explains the forest of #ifdef and accumulation of cruft.

All of these are missing the point imo. The biggest advantage of modern IDE is the ease in trying new plugins and functionalities. Everything is a menu away, and fuzzy searching makes it easy to find out commands and learn their shortcuts. This whole process just doesn’t exist in emacs. To get a plugin, it’s a huge step (setting up custom elisp to get melpa) and then it’s a huge learning curve just to try a plugin.

I've used Emacs for around 14 years now, I rarely touch my configuration. There's lines in my config today, that I haven't changed since I first learned to use Emacs and set it up (e.g. keybindings, tab-width, etc.).

I like that kind of stability, makes it possible to move my focus away from the editor, towards the problems I'm trying to solve.

Not a downside necessarily, but I can imagine that life would get very stressful if you're ever to lose your custom configuration for emacs.

It’s in a public git repository

And that's why you keep it in version control and mirror it to, say, Gitlab and Github.

Could burn an archive to an archival-quality DVD, too.

I suspect I'm more likely to die spontaneously than have all of those and my local machine fail spontaneously.

I don't really get what you mean. Sure, setting up MELPA is a bit annoying, but after that trying a new package is trivial. You go to the package list and install the package, then you trigger whatever command you need.

I agree that fuzzy search is a great thing though, and I think something similar to Ivy should be included by default.

> then you trigger whatever command you need

how do you do see? How do you get to the list of commands? How do you search for a command? How do you remember a shortcut if you run a command manually?

I've been using emacs for quite some time and I still get stuck there.

To run/search-for a command: M-x

If you have installed and configured helm (I assume the same for ivy) you'll get a list and the search will be fuzzy)

In helm: shortcuts are shown in the result list:

    M-x replac|
    replace-string
    replace-regexp
    query-replace (M-%)
    ...

In helm you can navigate the list with the arrow keys and TAB (not sure if it's the default key) will pop up an help buffer for the command

I don't use helm, tried for a while but got really confused by a lot of things. So when I do M-x I actually can't fuzzy search OR see what the shortcut version of a command is.

> The biggest advantage of modern IDE is the ease in trying new plugins

I don't think think pasting a few lines[1] into a file can be counted as a huge step? There's built-in UI [2] for installing and configuring packages.

To me the overwhelming advantage of an IDE is good semantic language support out-of-the box. Even having invested quite some time in language-support configuration in emacs I usually use an IDE instead.

> and fuzzy searching makes it easy to find out commands and learn their shortcuts.

This is a package (extension) away in emacs, and there's multiple starter configs which have this out of the box (spacemacs, doom, etc.). IIRC the vanilla experience have prefix completion of commands.

Emacs suffer a bit from having an enormous number of commands which kinda pollute the command-palette-search for everyday use.

Some of the quirky terminology takes some time to get used to (eg.: "open" -> "find")

Overall I find emacs discoverability to be very good and the documentation is comprehensive and well-written.

[1] https://melpa.org/#/getting-started (besides, the elpa repository is available out-of-the box)

[2] https://www.gnu.org/software/emacs/manual/html_node/emacs/Pa... (admitting you often have to use some elisp for more advanced configuration)

Pasting in a few lines is a HUGE step, because how are beginning Emacs users supposed to even know they are supposed to do that?

I see this every year with new undergraduates at uni -- they are often aware of vim, Emacs, VSCode and eclipse, and play around with them. They don't have any reason to believe Emacs and vim are good, and any step to get stuck at loses you a bunch of users.

Some students take up vim, but Emacs gets almost no use, as it doesn't (to the beginner user) seem to do anything well, and everything is hard to do.

For example, I'm trying to setup rust-analyzer with emacs right now, and the instructions here makes 0 sense at all: https://rust-analyzer.github.io/manual.html#emacs

I'm completely stuck at step 2 and 3, how can anyone parse this without being an emacs pro is beyond me

Maybe I can offer an interesting perspective. Compared to most readers on this site, I’m likely on the younger side, I’m 20, at a university, and I’ve been programming since I was ~14.

I used VS Code for the majority of my freshman year assignments, but decided to switch to emacs during my sophomore year, mostly because I’d heard interesting things about org mode, magit, and other packages, and I had a system programming class coming up that would require me to SSH into a VM and finish assignments on the VM.

The initial muscle memory shift was scary, I repeatedly gave up on learning emacs, only to come back a couple days later and attempt it again. I started with Spacemacs/Doom Emacs, but both assumed I knew vim, and I found feature discoverability to be complicated. The fact that many packages were included made things more confusing, I tried to figure out what helm and Ivy were, and how to configure things, etc.

The only time the process really stuck for me was installing vanilla emacs, reading a couple of tutorials on how the extension system worked, and just forcing myself to use it for every assignment I had. The built in tutorial was handy but I still don’t use the navigation commands most of the time. Nowadays, I can’t get out of emacs, I read my email in it, I use org mode for everything, and have it synced to my phone, I used lsp-mode at an internship this summer where I was writing Go, I’ve got autocomplete set up, etc.

While an easier experience would help get people into emacs, I think the fact that you can really customize it in any way you want initially forces you to learn a lot more about your editor than any other editor. If I want autocomplete, I need to go figure out how to set it up, but there’s a plethora of resources. It teaches you how to be a better developer, always looking for new packages and sharpening your tools.

I wonder what the appetite for extending the emacs "server" concept is. Treat it like an API and so that you can maintain core editor compatibility, but offer an easy way to implement UI layers that users might feel are more modern.

Could also lead to dedicated "org-mode" clients, etc.. that could leverage emacs under the hood via the API.

After using Emacs for 10+ years, I've switched to VSCode for a really simple reason: fuzzy matching a file in a project. I've tried so many different plugins and hacks to get it to work, but it never did quite work. Searching for a filename either matches the wrong file, or new files that were freshly added are no longer there.

Projectile + Helm works extremely well for me, did you try those modes?

I’m a vim user, but I imagine there’s a similar way to do this in emacs...

The secret is piping fd into fzf and opening the selected value from fzf. You can probably write a 2-liner in elisp that shells out.

In my experience, this pipeline provides a faster and better matching experience than any IDE.

Once I got this working, I never went back to VS Code. :)

If it’s so simple why don’t they build it into emacs?

Not sure if this was asked sincerely, but fzf is a fairly new program, relative to emacs.

https://www.youtube.com/watch?v=aXPQTesFdTI

The default solution in doom emacs does this really well! I think it may be ripgrep-based, like VSCode’s, but I’m not positive.

Wow so many people are switching to VS Code...

I’ve been a vim user for 22 years and I switched over to VS Code last year but only for development. I have to grudgingly admit that it’s just a more productive environment. I do like VS Code.

I still edit config files etc with vim though.

Projectile + helm (powered by fd) has worked wonders for me.

Being easy to use by newbies has killed too many great ideas already.

Emacs is in that disastrous stage of a product's life where the geezers destroy their own community by refusing to adapt to new expected behavior, thus driving away the newbies. Eventually the product dwindles to just supporting the few remaining geezers left.

I'm not talking about stupid fads such as skinning and color palette changes. But cut-copy-paste keybindings (not to mention select-all, save, close window, undo, etc.) are not a fad. They have been the standard in everything except for Emacs for over THIRTY FIVE YEARS. They were standard when Ronald Reagan was president.

Pop-up menus on right-button-click have been standard for almost as long, dating to X11 and NeXTSTEP (which is where OS X got them).

And the most awful trend is in preventing clear improvements in modes and functionality from coming to the forefront simply because geezers are not used to them. The argument seems to be that making all these kinds of things standard would be hard on the geezers. This is nonsense. Unlike the newbies, the geezers know how to turn this stuff off.

The geezers prevent this because Emacs is their ecosystem. But for everyone else, Emacs is a small part of a much larger ecosystem (MacOS, Linux, Windows) with which it is increasingly incompatible and archaic. This is myopia pure and simple.

Emacs has been at that stage for well over a decade, arguably two. What we're seeing now is the slow process of finally muddling their way out.

As an Emacs newbie (less than one year of usage) I could not disagree more. I disagree with basically everything you just said. If somebody wants notepad++, they should just use that instead of trying to turn Emacs into something it never was.

As an olive branch: Perhaps Emacs could prompt the user on first run what sort of control scheme they want. Emacs standard, Evil mode, or some notepad clone could be modes that ship with Emacs by default (evil already does.)

(I chose evil, because I came from vim. Maybe this is why Emacs was so easy for me to pick up. But by the same token, Vim is arcane compared to Notepad style editors but is quite popular, so I outright reject the hypothesis that Emacs has lower numbers because it's arcane. Rather, I think it has a marketting ''problem'' relative to Vim.)

> But by the same token, Vim is arcane compared to Notepad style editors but is quite popular, so I outright reject the hypothesis that Emacs has lower numbers because it's arcane

vim might be arcane compared to Notepad, but I've been successfully using vim as an editor of choice in ssh pretty much throughout the whole uni without knowing more than :w and :q (at which point it basically was a notepad). I was ever completely lost in Emacs though, with its nested C-x, M-x seemingly without rhyme or reason. I wouldn't "outright" reject that hypothesis without more scrutiny.

Anecdotally, I've been an Emacs (Spacemacs) user for a few years after that, and I never got used to all the commands I would use on a daily - but not hourly - basis, having to always look those up. But, as one of the other top-level posts said, what made me switch in the end were the language servers.

Vim drops noobs straight into normal mode, meaning the moment they start trying to type they get confused. I know that's what happened to me. The arcane nature of Emacs doesn't make itself apparent nearly so fast.

Only if it isn't invoked as "evim", "eview", "vim -y", or "view -y".

True, though a noob wouldn't know how to invoke it like that.

Yeah honestly I think a config “wizard” when you start up to get some basic standard stuff ready to go, like package installs, themes, evil/CUA/traditional keybindings, LSP stuff, some major modes, etc. would go a long way towards making it less intimidating and more productive out of the gate.

Also some kind of popup help for keybindings like you get with the Doom/Spacemacs leader key would I think help a lot.

I certainly don’t think that changing the color scheme or other “chrome” improvements are going to make any meaningful difference, and honestly the discussion in the article sounded kind of condescending, assuming that the only reason people might find emacs difficult to get started with is because it doesn’t have cat videos or a dark color scheme.

> Emacs is in that disastrous stage of a product's life where the geezers destroy their own community by refusing to adapt to new expected behavior

It doesn't look like your an Emacs user. As another commenter pointed out (as did the article indirectly), Emacs has more users than ever. It's definitely growing - not dwindling. As an Emacs user, the last decade has shown an immense growth in capabilities via MELPA packages. The number of sites with tips on improving Emacs flows has also gone up exponentially.

Not only is it not dying, it's thriving.

> They were standard when Ronald Reagan was president.

For a whole other definition of standard. A lot of the popular DOS applications from Reagan/Bush's time did not use these keybindings. Ctrl-Ins and Shift-Ins were the norm. Ctrl-C for quitting was the norm.

(I'm not against CUA bindings by default - merely pointing out a misconception you have).

> But for everyone else, Emacs is a small part of a much larger ecosystem (MacOS, Linux, Windows) with which it is increasingly incompatible and archaic.

Actually, Emacs is pretty good at interacting with the wider ecosystems. It can communicate and interact with other processes, etc. I can, for example, link to a message in MS Outlook and have it open up in my TODO list in Emacs.

> It doesn't look like your an Emacs user.

I have been an avid Emacs user since, I think, 1988.

> A lot of the popular DOS applications

Bzzt. 35 years ago the standard was Windows and MacOS. Soon thereafter NeXTSTEP and nearly all X11 apps adapted the same.

While Windows technically existed in '85, no one statistically was using it yet. Other's copied the CUA interface into the late 80s however.

Windows didn't start going anywhere until Windows 3.0 in 1990. Windows 95 was really where it went mainstream.

> Emacs has more users than ever. It's definitely growing - not dwindling.

Growing in terms of the number of users, dwindling in terms of the share among editors

Market share shouldn't matter.

The numbers that do matter: Are the number of contributors increasing, decreasing, or stable? Are the number of users increasing, decreasing, or stable? Is the rate of increase (if increasing) for either of these itself increasing, decreasing, or stable?

As long as contributors and users are both increasing, you're probably ok. As long as the rates of increase are at least stable, you're ok.

It's not like this is a life or death struggle, emacs will probably outlive us all.

>Growing in terms of the number of users, dwindling in terms of the share among editors

That's as may be. Just because something has a high market share doesn't mean it's the best product.

Chrome is by far the most "popular" browser by market share, and that doesn't stop it from doing all kinds of stuff that benefits Google over users -- often to the detriment of those users.

Historical note: CUA didn't come along until 1987. In 1985, the Lisa had been out for two years, and CUA was that far into the future, as indeed were Windows 2.0 and OS/2 1.0.

It's true that the claim that the Mac/Lisa key chords were the standard 35 years ago is quite wrong. But it's false to claim that there was another standard instead.

I don't really buy the argument I'm afraid.

I've been an Emacs user for over 20 years. I like it, and find it productive. But it's stuck in a rut, in a very similar manner to Perl 5. If that isn't addressed, it will fade into the background. I'd argue that's already happened. None of my coworkers in any of the jobs I've worked in have used it, and that includes academia and various industries. It seems to be restricted to the uber-nerds who find out about it and go through the pain of learning how to drive it effectively. I used to use it for everything, from GNUS to org-mode, but my usage is declining.

The keybindings need to be fixed. CUA has been the norm for what, 35 years at this point. C-y is paste. C-z minimises the window (WTF!) C-_ is undo. It's not just nonstandard and counterintutive, it's unnecessarily nonstandard and counterintuitive. They aren't more efficient, they aren't more effective. It's a barrier to adoption which doesn't need to be there. It has a certain familiarity for us long-time users, but that's about it. Every other application uses something based on CUA, so it's not like we couldn't switch over.

While I certainly wouldn't want a "GNOME 3" type of makeover, where all the actual userbase are cast aside to be replaced by a hypothetical potential userbase which doesn't actually exist, I do think it's well worth a look at present-day alternatives and to make sure it doesn't fall behind. Because I think it actually has fallen behind, and it needs to get its act together to retain its relevance.

Recently I got a personal JetBrains subscription and started using CLion. While I still miss many little small features, there are quite a number of big features which Emacs doesn't attempt to do, and so the small annoyances are worth it for those large benefits. Emacs needs to be able to do better than this to not only keep up, but to do better than its competitors.

I said:

> (I'm not against CUA bindings by default - merely pointing out a misconception you have).

And you respond with:

> I don't really buy the argument I'm afraid.

And then you write a whole comment about how CUA is better.

Which argument did I make that you don't buy? Why is this a reply to my comment?

> I do think it's well worth a look at present-day alternatives and to make sure it doesn't fall behind.

In all my jobs that used IDEs (including JetBrains's excellent stuff), I used both the IDE and Emacs - the latter for text editing, etc. The former for all the goodies it brings (navigation, etc). There's no law saying it has to be one or the other. IDEs becoming very popular in no way threatens Emacs.

> Because I think it actually has fallen behind, and it needs to get its act together to retain its relevance.

I could really easily write a whole article on all the features Emacs has that many more popular editors don't have, and then end the article with "Those other editors are falling behind."

We have to clearly delineate what "falling behind" means, and whether it is relevant. VS Code gaining in popularity doesn't necessarily impact Emacs. In my career I've met an order of magnitude more Vim users, and Emacs is not the worse because of it. Emacs's capabilities have grown much faster than Vim's has, and Emacs has a lot more users than it used to. Furthermore, most Vim users I've encountered at work are not fairly advanced users: They just need something to edit files with. Having them switch to Emacs will neither help them nor the Emacs community.

I don't mind some of the proposed changes (nicer defaults, revamping the tutorial, etc). But I really don't want a mindless goal of increasing user counts. More users will not make Emacs gain more capabilities. Passionate users will.

>The keybindings need to be fixed. CUA has been the norm for what, 35 years at this point.

M-x cua-mode<return>

Oh, and you're welcome.

Thatcs not the norm. That's an off-by-default feature that doesn't display its existence to people who would use it.

>Thatcs not the norm

So what? Is your argument that if not many people/products/software packages do a certain thing a certain way, they should be rejected out of hand?

Back when I was a teen, I rode my skateboard goofy-footed[0]. That wasn't (and still isn't) the norm. Should I have been chastised or prevented from doing so?

I'm also left-handed. While I do keep the mouse on the left side of my keyboard, I do not swap the mouse buttons. As such, a right-click is done with my index finger and a left-click with my middle finger. That's not the norm either. Should I be criticized for that?

Chrome is, by far, the "norm" for web browsers. I use Firefox, and occasionally Vivaldi. Should FF or Vivaldi just make themselves clones of Chrome because they're not "the norm"?

I run sendmail and not postfix, even though that's much more "the norm." Does that make my MTA bad or less useful?

I could probably rattle off a dozen other similar things that aren't "the norm." Does that mean no one should do things that way or use them?

If you want/need an editor that uses CUA by default, there are dozens of editors that do so. Why should Emacs (or any other product that you don't contribute to or use) do things the way you want them to do so?

[0] https://www.liveabout.com/goofy-meaning-3002686

If it's so easy to switch, and a beginner is more likely to want it on, why not set it on by default and let everyone who wants it off put it in their config?

>If it's so easy to switch, and a beginner is more likely to want it on, why not set it on by default and let everyone who wants it off put it in their config?

Why is it important to prioritize beginners over experienced users?

I can understand that point of view in the context of a new product, or one that is struggling to make money from an existing product.

But last I checked, Emacs is free software, with no impetus for increasing "user counts" or "market share," since "revenue" from "sales" of GNU Emacs remains the same regardless of either.

Perhaps you might ask the fine folks over at Lugaru Software, ltd.[0] why they haven't done so.

Espeially since they've been selling their emacs-based Epsilon Programmer's Editor since 1984[1][2], which, incidentally, was before GNU Emacs was available for any desktop computers.

[0] https://www.lugaru.com/

[1] https://www.lugaru.com/history.html

[2] https://en.wikipedia.org/wiki/Epsilon_(text_editor)

> Why is it important to prioritize beginners over experienced users?

In my opinion, because experienced users know how to configure their editor while beginners don't.

If "every expert" has their own tuned configuration, they really shouldn't care what the defaults are. It is (in my opinion) crazy to have options designed to make a system easier to use, which have to be searched out and turned on.

If Emacs doesn't care about user counts or market share, great. Emacs users can stop posting about it, and it can quietly fade away.

The CUA issue seems frivolous, since retention among those who don't even do the built-in tutorial on the splash page was never going to be high. It might help somewhat, but the bigger issue with emacs is the association with spacemacs (vi), lisp, and "configurability", which attracts some but perhaps leads many more to disregard emacs as Kool-Aid and never even try it. The reason to use emacs is that the text-editing is superior. magit, org-mode, email, and so on having an unified interface is great, but the text-editing (navigation, mark and region, macros, rectangles, and more) is what I miss acutely when using anything else, and it's also the reason why the rest of emacs exists.

Is it really necessary to ascribe some negative quality of ageism to people who created and use software and then castigate them for it? Do you work for PeopleSoft? Makes your argument seem weak and flimsy, in fact arguments like yours can be dismissed out of hand.

I am one of those geezers.

Doesn't pass the switch test.

I've developed software since the early 1980s. I've used Emacs continuously since the late 1980s. Perhaps you should respond to the substance of a posting rather than complaining that a geezer used the term geezer to describe people like himself.

EDIT You created your account two days ago and you're already accusing people of ageism? Get off my lawn.

Another geezer here. Using Emacs since Bush I.

Emacs is in that blissful state where it's resisting sacrificing its core user base by trying to cater to people who are not going to use it anyway.

As a long term user I am very happy with the direction of Emacs development over the past few years. Emacs is pretty much the only piece of modern software where I don't have worry about losing functionality when I upgrade to a new version. Each new version is better than the old one.

Don't know what platform you are on, but on Mac with the GUI version, standard cut-copy-paste keybindings all work, as well as select-all, save, close window (Cmd + w), undo.

Obviously they don't work in terminals.

I’ve used emaca for a pretty long time- since about 2001- but in all that time I’ve never felt the need to become a super power user- it just does the basics really well. I guess that’s all I really wanted. I use it for coding and I use org mode. I like the auto-indentation, which to this day no other editor can match, I like the syntax highlighting.

Here are my beefs though:

1- you have to jump through hoops to get melpa to work- I have to research this again every time I install it.

2- the auto indent and syntax mode for shader language has to be installed manually

3- ido-mode isn’t turned on by default

I’m one of those doofuses that uses cua mode all the time too. Sue me, I just want an editor that works and emacs is very good for code editing. I don’t care about the power editor moves which I forget 5 minutes after learning anyway.

Coming from the standpoint of a new emacs user/young programmer I found that my problem with base emacs is getting to a minimal viable setup just took to much time.

It wasn't until I learned about spacemacs that I gave emacs another try and I haven't gone back since.

I've been checking out alternative text editors, and was recently impressed with micro[1].

The only issue I have with it is that it doesn't handle text navigation with the Ctrl + arrow key combinations that let you jump to the start and end of words.

There's a small revival of modernized text-based apps now that Go and Rust gained adoption. I've even come across an editor written in Nim, called moe[2].

Are there other editors out there that are worth trying out?

[1] https://github.com/zyedidia/micro

[2] https://github.com/fox0430/moe/

I agree that "Emacs needs its NeoVim moment", where some architectural changes are needed for future longevity (I'd want it to be around for my lifetime!), but I also don't think there should be any breaking change.

I have already, over the last decade, seen incremental changes to make packaging, json-handling, concurrency, much better than they used to be.

But most encouraging of all, the "distributions" (Doom, Spacemacs) are doing some of the "market research" about what users like more, or care about more, and cataloguing the lesson learnt there would help Emacs move forward in an /incremental/ manner.

I've recently become an "emacs convert", one of those annoying types who are wet behind the ear and have stars in their eyes.

The critical features that have led me down this path have been Org Mode and Doom Emacs, the vim keybindings are what I'm used to and it works well.

Will check in with myself in 6 months or so but so far it's been real joy to use, I develop in Go at work and I've had no issues with the LSP mode or anything and it seems to run pretty performant, even with the largest projects.

I'm not too well versed in everything though but I'm muddling my way through, the menu bar at the bottom when you hit SPC helps a lot.

Seems like we should treat "Emacs" more as a platform than an editor. You then take that platform and build your own editor (and perhaps many other things!) on top of it. E.g. Doom, Spacemacs.

Why make Emacs another non-Emacs editor? Having mentored people (programming Clojure) who tried to learn Emacs via Spacemacs or some other "make it dumb" package, even after 6 months, they understood nothing about Emacs. They couldn't solve problems not solved by the "make it dumb" package. While I appreciate the effort going into these packages, I don't see them meeting their goal: Helping people to learn Emacs. They only help people to not learn Emacs while using it like a standard editor.

We should stop making the tutorial prominent and stop worshipping it. I've used Emacs for 20 years and write emacs-lisp packages and I don't use all those weird keybindings for moving around the buffer. That's what the arrow keys are for! There's an international aspect to this: those who went to school in the USA typically touch-type; but in some other countries one does not learn to touch type unless one is aiming to become what used to be called a secretary.

I've been using Emacs since it was a set of teco macros. (Yes, there was an Emacs before Emacs lisp.)

Apart from some settings to keep a keyboard-grabbing co-worker happy several jobs ago, I haven't had a config file in decades.

My experience has been that whenever I need something news, Emacs had it several years before. The most that I've ever had to do is update to a version that isn't 10 years old, and that hasn't happened for a long time. (I keep computers for a long time and the first thing I do with a new computer is install Emacs. I rarely update it.)

I've looked at other text editors. They seem to be better on things that don't much matter to me. They often require configuration to do things that Emacs does out of the box.

Yes, there are some things that I'd like to be different and about every year or so I think about adding a config file, but then I ask myself whether I'm going to propagate that config file everywhere I use Emacs. So far the answer has been "no".

For me a "modern Emacs" would basically be Notepad++ with more advanced features and programmability. The few times i tried Emacs (and i actually used it for a bit back in the early 2000s on a crappy Pentium 1 laptop i was given - and yes, i did felt the "Eight Megabytes And Constantly Swapping" meme of the 90s, though it wasn't that bad :-P) over the years i always dislike how it just doesn't mix with the native environment at all (be it Mac OS X or Windows... Linux doesn't really have a native environment and interestingly the longest i used emacs -that laptop- was under Linux :-P). Also for some reason it always felt a bit sluggish - you'd think with faster CPUs (and Emacs not having to follow fads - unlike, e.g. browsers) it'd be faster, but it always felt sluggish to me no matter what.

In general i like the idea of Emacs: a fully programmable editor that can be extended as much as you want. I just do not like the current application of that idea.

I mentioned Notepad++ because that is the editor i'm using the last few years and i like how fast it is (it opens instantly even with hundreds of files/tabs open - that it remembers the open files from last session and remembers changes in unsaved/new files is also very useful because i use it often for taking short lived notes) and how few resources it uses (it currently only uses ~15MB with a few tends of files open). But it does feel limited with pretty much zero way to customize its behavior - it is basically someone's custom configuration over Scintilla hardcoded in an executable.

However what i really like about it is that it uses (almost) the same keybindings i've used for decades and it looks and feels like a proper native Windows application like the applications i've used for decades. It basically lets me take full advantage of all the knowledge and experience i've developed over the years instead of expecting for me to throw that away and instead spend time learn how to do mostly the same stuff in a different way. And it is also very lightweight, did i mention that? I think i did, but it deserves repeat.

(the reason i use NPP is also why i do not care about VSCode or Sublime... they both feel alien and while Sublime is supposedly fast, i do not like its UI - also i do not think it is as programmable as Emacs or VSCode, but i might be wrong there...)

Perhaps there is Notepad++-alike which is also programmable and more powerful, but i just do not know it.

I think Emacs is nearly perfect. I use it everyday at work for different tasks. But I can't seriously recommend it to anyone.

I'm looking at my configuration file now. It's 1300 lines of elisp. It took me 4 years to make it bullet-proof. I can't ask anyone to make that kind of investment just because I think Emacs is great.

I love org-babel (executing code blocks with a text document, like jupyter notebooks) for technical documents. I know of nothing comparable. The rest is a messy pile of possible frustration.

I would happily trade emacs modernization for a standalone Babel like system, that could be used with whatever editor. Maybe like LSP to vscode.

I had a look, after posting this comment to various other tools allowing to run code within text to produce tech documents.

There are quite a few, mostly for markdown, and mostly limited to literate programming. See rundoc, codedown, gfm-code-blocks.

Here's a new user perspective on Emacs (based on memory; I actually have more experience than this):

I open emacs-gtk. A document is already loaded. I try to type something, and every letter I type gives the unhelpful error message "[letter] is undefined". I guess this means I need to create a new document first. I open the File menu, and see "Visit New File...". "Visit" sounds weird, and the "..." is suspicious, but at least it has "New" in it, so I pick that. It opens a file picker, so "Visit New File..." must be Emacs slang for "Open...", and there is apparently no "New" functionality in the File menu. There's also an "Open File..." menu item too for some mysterious reason, but that's obviously not what I want, so I ignore it.

I check the Help menu. This has 19 (!) top level options, none of which are obviously correct, and one of which is "Emacs Psychotherapist". I click that one out of curiosity. It replaces the starting document without warning and there's no obvious way to get it back. I'm presented with more Emacs slang. I assume "RET" means Enter, and that Psychotherapist must be a Microsoft Clippy clone.

I type "new document", hoping it will search the documentation. I immediately notice the scroll bar flickering. This draws my attention to the incorrect size of the drag handle. I click the empty space below the drag handle, which moves the drag handle but doesn't actually affect the text. I drag the drag handle back up, which makes the text glitch out for a moment, but otherwise does nothing.

I press "RET" twice, and get "Why do you say new document?" I then realize that it's actually an Eliza clone not a Clippy clone, and I've wasted my time. I give up on trying to create a new file, and just Open an existing one. I immediately notice the cursor is an ugly inverse video cursor instead of a normal thin line cursor. I press and hold the down arrow key, and notice that scrolling moves in big jumps instead of line-by-line. It also forcibly moves the cursor. It seems the cursor lives in screen space like it's still the 1970s and I'm using a hardware terminal. There is no obvious way to keep its position in the document while you navigate somewhere else. Despite this, Page Up cannot move the cursor to the beginning of the document like it should. Page Down works though.

I assume that, like every modern text editor, there's a "Find in This Document..." feature bound to Control-F for easy navigation. There's not: Control-F is bound to right arrow. Presumably this made sense 40 years ago. There is not even any Find functionality in the Edit menu, which you'd think would be core functionality for any text editor.

In the course of this experimentation, I notice that merely moving the mouse cursor over the scroll bar is enough to make it flicker. I hold the scroll down button with the mouse. It actually does scroll, but extremely slowly, averaging about one line per second. The timing is inconsistent, and the CPU usage is strangely high.

I type something, and notice that there is no visual indication that the document now contains unsaved changes, such an asterisk in the title bar, or a dot on the Save icon. I press Control-S to save, which doesn't save, and instead triggers the Find function I was looking for. I decide that "Modern Emacs" is a hopeless quest and give up in favor of something written this century.

Responding in your same spirit: Did you notice where it said "Tutorial" in the starting document you ignored, or where it said "Tutorial" in the help menu you ignored?

Most likely yes. But the only reason I tried Emacs in the first place was because I knew it could do complicated things. I expected "Tutorial" to be the place to get started with those complicated things. It didn't occur to me that a tutorial would be necessary for such seemingly simple operations.

I did later go on to read tutorials, and I put many hours into customizing my .emacs file, but I always felt like I was fighting the system. Emacs is designed for hardware that's now museum pieces, and those design decisions have pervasive effects that make it impossible to configure Emacs to act like modern software.

I will refrain from commenting on the general dismissiveness in your post, and stick to one of the points you made: "Ctrl-F" being linked to "move right" is the /standard keybinding/ on macOS.

In fact, /most/ of the "standard" Emacs keyboard shortcuts (Ctrl-F, Ctrl-B, Meta-F, Meta-B, even in some contexts Ctrl-K, Ctrl-Y) are /also/ the standard macOS keyboard shortcuts.

How about instead the Emacs website and splash screen recommends different `flavours' of Emacs instead? Such as Doom and Prelude for example. No reason to change vanilla Emacs.

Stop having Emacs be the recommended way to install and use Emacs.

If only there were projects that repackaged Emacs together with packages which adapt the program for people who prefer other keybindings. And failing that, maybe Emacs should include some facility for remapping key bindings?

I don't understand why you're sarcastic, it's as if you did not read my post.

I tried Ergo Emacs, because I like Xah Lee's attitude to modernization, but even somebody so willing to abandon old defaults can't make Emacs feel modern. Emacs makes assumptions like "a document has a backing file on disk" and "a cursor has a location on screen" that only make sense with obsolete hardware. The weird janky feeling is embedded too deep for any easy fix.

> If only there were projects that repackaged Emacs together with packages which adapt the program for people who prefer other keybindings. And failing that, maybe Emacs should include some facility for remapping key bindings?

The sarcasm here isn't warranted, the request wasn't for for distros of emacs to exist, but for them to be promoted to prospective users on the emacs website over a bare install.

My objection isn't to repackaging emacs with new defaults, but promoting forks and such on the emacs site. That's not what GNU does with other forks historically either.

What'd be the point of it all? There are perhaps dozens to hundreds of personal takes on emacs on Github and around the web. emacs will remain as it is, it isn't for some people and that's OK.

As I understand it, these distros aren't forks at all. Promoting them would give an emacs beginner a better onboarding experience, and make it less likely that prospective new users give up in frustration.

They didn't even mention the most appalling non-modern aspect of Emacs: scrolling the page moves the cursor. This never happens on modern editors but it drives me crazy about Emacs and it's non-fixable.

Ha, that's something I love about Emacs and drives me crazy whenever I use something else.

The Emacs user interface, I think, the general text editor, is slowly dying. We can see in the LWN article that it is very reluctant to change, and this is what evolution has learned me: if you cannot adapt, you die. Most software never make it as far as Emacs have, in any case. So it is not a failure.

But is it possible to keep Emacs as a powerful tool, working from behind, in other tools? Like a utility you drop into for specific tasks? Magit for example, or org-mode. Could that be a future for Emacs, to be integrated as a a backend for some tasks in VSCode?

For better or worse, I feel that one "simple" change that would make any project more attractive to newcomers is switching to GitHub for development.

I'm sorry but I feel like it's a lost cause at this point. There are probably more than a dozen other editors that _are_ modern. So if someone wants a new alternative probably all that is really missing is some syntax highlighting definitions. And you can probably port them over from an existing system automatically.

OR, create an Emacs distribution that is preconfigured to be more modern.

I like TextAdept. It's fully programmable with Lua.

I admit that out of the box Emacs is underwhelming. The popularity of Doom, Spacemacs and Prelude show that.

I actually had been working on a config for noobs. Which basically make it feel like Atom. I think having a choice between that or standard when you start Emacs could be a win.

I also agree that the mouse UX should be modernized. It's just bad, I mean, I barely use the mouse, but also the mouse UX is crippled so I don't want to use it.

I’m by no means an expert on this subject but isn’t this a bit like xemacs? More mouse-driven. Friendlier menus. Sure, rough by modern standards but why not just contribute to that project? I felt it was a pragmatic approach that kept the emacs patterns and usage intact. If you VS Codeify Emacs, is it then even a modern Emacs?

Edit: OK maybe xemacs is no longer actively developed, but sxemacs then.

It would probably be better to sell people on the parts of emacs that don't involve text editing - like eshell, dunnet, magit, orgs mode.

The original mail thread says "winmove" is available but not enabled by default https://lwn.net/ml/emacs-devel/20200906133719.cu6yaldvenxubc... How to enable "winmove" ?

Making it easier to set colors sounds fine to me.

It probably won't make it attractive to many more people (personally I didn't find inverting the colors hard...) but at least it doesn't gut what makes emacs useful and interesting in the first place.

... which isn't something you can say about every improvement people suggest. :)

I think that the article brings up good points about how to make the default install of emacs better for new users.

On the other hand there are many alternative versions of emacs that solve this problem like Aquamacs.

Maybe instead of changing the core version instead the FSF could make or suggest an emacs for beginners .

The new people don't even know the joke about the email!

I teach them, and then every time they mention Sublime, I ask them whether you can read email with Sublime.

I used Emacs as my exclusive DE when I was started programming (can't argue with free) but as I started coding professionally branched out to other IDEs; however, I am back to developing with Emacs 100% of my time. A rough history of editors would be:

* VisualBasic (HS)

* Emacs/R

* Spyder

* PowerBuilder/Emacs

* PyCharm

* SublimeText

* Visual Studio Code

* Emacs (but now full time)

Even when I wasn't using Emacs for the bulk of my development work, I still preferred it as my terminal editor of choice and fter having to configure Emacs from scratch several times, I finally decided to spend some time to try and make my Emacs config portable:

> https://gitlab.com/gshulegaard/my-emacs

My takeaway from doing that was both positive and negative. On one hand, Emacs is extremely customizable and it was pretty rewarding to get my set-up just right to fit my needs. On the other hand, it is extraordinarily time-intensive to do so. Even as a reasonably seasoned developer with almost a decade of experience _using_ Emacs, installing extensions and configuring them to work together is a pretty off-putting task.

For example, even before installing an extension you first have to answer, where do I want to download it from? To which there isn't an obvious answer. My personal config actually configures 4 separate package archives:

> https://gitlab.com/gshulegaard/my-emacs/-/blob/master/src/cu...

Once you have an extension installed, there can often be additional steps or dependencies which have to additionally be managed. Which I get; Emacs is not a IDE, it's an extensible text editor so it probably shouldn't try to be more than that. But if the goal is improving usage then I think improving extension management (and by extension configuration) should be the top of the list.

In my opinion, suggesting changing default key-bindings, right-click behavior, or theme are just dancing around the elephant in the room which is: The world has moved on from plain text editors and Emacs is just not as approachable as IDE counterparts.

Honestly, this might be fine! Even when using an IDE for development work I still reach for Emacs when doing terminal text editing or want to manage multiple shell buffers from a single SSH session. But if we want to have a discussion where the context is waning Emacs usage is a problem, I can't help but feel we have to start with extension and configuration management. It's hard to justify spending the time required to install and configure Emacs with extensions when there are alternative tools that require almost no additional components or offer nearly one-click installation processes (e.g. SublimeText and Visual Studio Code).

I've been coding for almost 40 years and never used emacs. We all have our own tools and practices. To each their own.

I am using GNU Emacs since 1999. It was one of editors in the back then Red Hat Linux distribution that I got my hands on at the train station bookstore in Stuttgart, Germany. In fact I was searching for GNU system, but larger library Witwer was closed in the evening, and I was furious that my "Windows" blocked itself, it did not have the true multi-tasking. My purpose was to find the multi-tasking, and I was of the opinion that GNU is yet another proprietary Unix like operating system. There was some license shown, I did not even want to read it, I was disgruntled with licenses, and have never respected proprietary licenses. My downloads were mostly from Warez websites, so I could not care less.

How wrong I was?! By using GNU Emacs I have discovered what is really free software. I was pleasantly surprised that I could distribute that software without fears of getting caught in Germany, I could even modify it, and what a pleasure that I have got so many programming languages available, for which I would need either to spend money otherwise or search through Warez websites.

Emacs and Vim both were my primary editors for years. I liked nvi for simplicity even more, but it did not support UTF-8 back at the time, yet I used it whenever there was need and still do today. For simple text editing, I am using vi, nano, and emacs in console, as mostly I access remote servers and need to handle either emails or configuration files.

At my office, I am using GNU Emacs for anything, it is my universal window into the computing. My Window Manager is Emacs X Window Manager or EXWM, so any video or music, I am running it through Emacs and I am using 10 workspaces.

By keypress, I am seeking through the names and locations of one of my 195877 contacts, and Emacs displays list of such contacts, by one keypress like F3, I can edit contacts where PostgreSQL is used as background database, I can open the Org file for the contact to manage contact's tasks and transactions, I can send SMS, or initiate the call through one of 3 connected mobile devices. Emacs is deciding which source phone number will be used to initiate the call by looking into the prefix and network of the destination number. If I wish to inform contacts, I will send them automatically emails and follow ups, all working through Emacs and programmed with small Emacs Lisp functions, using system software. More than 650,000 emails have been sent already. Customer relationship management is at my fingertips and need no external server. Staff can access my database and manage it through the virtual private network. If I wish to share my contacts, I can export the vCard and quickly send a file to one of my contacts, I press this window key on left side and m, and I am asked for contact name, then I choose one of emails, and file is sent to the contact. Skills and various marks or tags can be added to contacts. Quick subscribing of a contact to a group is easy possible by using Helm.

Most of my needs are satisfied with Emacs Lisp, it helps me to extend the editor to the point that I can make sales in amounts of US $100,000 quicker and easier than back then by using Thunderbird, or terminal and mutt. Yet I could not get rid of the mutt email client due to its increadible speed and customization so I am launching mutt within Emacs inside of the emacs-libvterm terminal, that works so well and integrated.

By using some of Hyperbole and Org Mode ideas, I have made the Hyperscope, my hierarchical database backed collection of hyperlinks that helps me and my mind orient and plan better. It creates Org files when necessary or views videos at exact sections or directly brings me to the referenced PDF page.

It is fricking extensible through hundreds if not thousands of various packages.

What I don't like is too many themes to customize Emacs, so I am just using the default themes, and switch from time to time.

Those are my personal use cases, I am quick and efficient, and none of other editors is offering me that type of extensibility to do what I want as Emacs does, and it is all thanks to the built-in Emacs Lisp engine and ready interface that works both on the X and on the console.

References:

- Emacs https://www.gnu.org/s/emacs - GNU https://www.gnu.org - Why GNU developed GNU Emacs and the GNU system: https://www.gnu.org/gnu/thegnuproject.html - GNU ELPA: https://elpa.gnu.org/packages/

Why not have an intro tutorial when opening emacs for the first time?

IMO emacs is not designed to be sold, its designed to be found.

Emacs' very-hard-to-fix issue is that it's based on a grid of characters. This means it will never be able to do many nice IDE things.

Emacs will never be a GUI-only editor, it was designed for a terminal and that is still a use case that many people take advantage of.

Don't worry though - if you don't like Emacs you can use any of a number of other editors.

What can you not do with a grid of characters exactly?

I think we're seeing a culture clash between people who come from a computing background where the terminal was either not used at all, or was a second class citizen, and people who come from a background where a terminal is the main way to interact with the system and the GUI is relegated to mostly showing terminals and doing the GUI-oriented tasks that can't be easily accomplished in the terminal, like pixel-image editing and drawing.

Edit natural language documents without wasting about 1/4 of your screen width on useless column alignment information.

Nicely formatted math. Gui designers. Diagrams.

And personally I find tabs is the most efficient design for switching between files.

> Nicely formatted math.

Can you elaborate? With a keystroke, it renders a LaTeX formula inline.

Oh nice! I guess it's less limited than I thought!

this could sway me, as a novice, whats the mininum amount of steps (from necessary packages to install to actual inline math output o screen) to demonstrate this?

First, the proper way would be to use the appropriate mode for LaTeX (auctex). It has a keybinding.

I don't use that mode, though, do I can't tell you how to set it up. I use org-mode, which lets you embed LaTeX formulae. I use this often, but surprisingly am not seeing anything in my Emacs config for this, so it may work out of the box. You do need some packages installed on your machine (dvipng, latex, etc). I already had them installed, so for me it was a simple matter of the keybinding: C-c C-x C-l

Details from the manual:

https://orgmode.org/manual/Previewing-LaTeX-fragments.html

Perhaps a friendlier guide:

https://orgmode.org/worg/org-tutorials/org-latex-preview.htm...

If you're not familiar with org-mode, it is highly recommended. Its learning curve is quite shallow. I'm sure there are tutorials out there, but for me the Google Tech Talk was enough to get me started and convince me I should use it:

https://www.youtube.com/watch?v=oJTwQvgfgMM

Ever since I encountered org mode, I author everything with it: LaTeX, HTML, DOC files, etc.

thanks, that worked, I was down the auctex rabbit hole, and got stuck on a 'cannot load file... cdlatex' or some such...

C-c C-x C-l worked out of box!

Weird, once I have C-cxl'ed a fragment to rendered latex, and the C-cc'ed back to monospace, I am no longer able to insert superscript and subscript symbols, and it complains about cdlatex-superscript or cdlatex-sub-superscript...

cdlatex likely is very useful if you plan to edit a lot of formulae. org has its own org-cdlatex minor mode (also needs effort to set up).

reinstalled the org package restarted emacs, and now it works

It feels like vim is finally winning?

All the functions without the hurdles, vim plugin is also numerous and pleasing.

intellij for java, emacs for everything else

I think if you could easily install and use emacs to edit a text file with no knowledge it's userbase would grow exponentially overnight.

You can. By default it boots up with a menu bar and toolbar, with familiar buttons to open and save files. Most keys do exactly what you expect.

This does not affect the size of the userbase much. If your needs are that simple, just stick to any basic editor you're already familiar with.

>I think if you could easily install and use emacs to edit a text file with no knowledge it's userbase would grow exponentially overnight.

Why do you put such a value on growing the user base exponentially? Is that important? Or even desirable?

Emacs isn't a toaster or even a web browser. It has specific use cases that a very small number of people actually need. The really nice part about it is that it's extensible and endlessly modifiable.

Again, that's not something that most folks need.

Oh look. It's THIS thread again

Reply on news.ycombinator.com