Making Emacs Popular Again - <AUTHOR> https://lwn.net/SubscriberLink/819452/1480c3a59d3d9093/ <comment><USER4> New employee 1 workflow at company X:

1\. Install VS Code

2\. Click extensions and install language specific plugin

3\. Work

New employee 2 workflow at company X:

1\. Install emacs

2\. Try to install some source code indexing tool

3\. Tool is missing 13 dependencies, so spend 4 hours finding, installing and configuring the dependencies.

4\. Spend another couple hours reading non-existent to terrible documentation (documentation so bad in places that even Stallman finds it useless) across 3 packages and editing .emacs to configure an otherwise unusable result. It looks like source code indexing is working! It isn't...

5\. Go home

6\. The next morning, find the default color theme garish and spend another 4 hours installing themes and theme managers, reading more terrible documentation, and finding that obscure TTY settings must be tweaked for emacs to decide that it can use a theme (even though it has no problem displaying the colors in the first place)

7\. Spend the rest of your tenure constantly hitting code indexing and highlighting bugs that need constant tweaking and workarounds. You often find yourself using find/grep because it's often faster than debugging the latest indexing bug.

8\. Discover that the vaunted 'lightening fast editing' with 'multiple cursors!' and this mode or that mode don't matter because the slowest part of the creative process is the creativity and not your typing.

Emacs is a terrible experience with defaults suitable for a 70s TTY. That you can change it misses the point. The fact that everyone has to have a non- empty, non trivial .emacs file means it is maximally unsuitable - <USER2> everyone.

In a few years, VS Code has achieved better out of the box functionality for working professionals than emacs has in 40 years.

<comment><USER5> New employee 3 workflow at company X:

1\. Install Emacs

2\. Sync existing config via git

3\. Work

New employee 4 workflow at company X:

1\. Install Emacs

2\. Spend 2 hours learning default Emacs

3\. Work

New employee 5 workflow at company X:

1\. Install Emacs

2\. Spend 1 - 2 hours learning default Emacs

3\. Spend 2 - 4 hours googling interesting Emacs packages, in each case going to their GitHub repo to read the directions, adding a use package form to your config with the settings that seem best from reading the directions and testing it to see if you like it until you have a useful set of functionality

4\. Work

You can probably spend plenty of additional time tweaking emacs to be everything from your mail client, your music player, your IRC client, insert task here but if you do this in the time you would be watching Netflix instead of the time you are supposed to be working you probably wont have trouble getting your work done.

I literally have no idea what you are talking about insofar as TTY settings, themes, indexing bugs highlighting bugs, or constant workarounds. I installed Emacs the graphical application, opted to spend 2 hours reading a book wherein I learned how to use emacs and picked a theme by searching for the string emacs theme and picking one that looked cool. I ran package-install typed the name of the theme, hit enter and evaluated (load-theme 'theme) in my config.

I have no idea why you would be running Emacs in a terminal in the first place.

<comment><USER6> Don't forget:

New employee 6 workflow at company X:

1\. Install Spacemacs, don't bother fiddling with the config

2\. Spend a few hours working through the tutorial or reviewing the excellent docs [1]

3\. Work. Become a better developer [2].

[1]:[https://www.spacemacs.org/doc/DOCUMENTATION.html](https://www.spacemacs.org/doc/DOCUMENTATION.html)

[2]:[https://blog.osteele.com/2004/11/ides](https://blog.osteele.com/2004/11/ides)

<comment><USER7> 1\. Install Spacemacs.

2\. Observe a flurry of errors every time you start emacs. Ignore and hope it works because no idea how to fix any of it.

3\. Find, among a million others, the command that seems to do what exactly what you want. Command gives an error. Dunno how to debug.

4\. Watch emacs features that should work ootb not work because spacemacs or evil or one of the three bazillion packages did something that broke it. Dunno how to debug.

5\. Complain on HN, get told you need to be using the master/develop version of packages because upstream devs don't care about maintaining stable releases.

6\. Use unstable packages. Observe new errors whenever you update or do anything. Hope it doesn't break more than it's already broken.

<comment><USER8> This.

While Spacemacs is an admirable effort, I think it misses the point: Emacs is an editor for power users from another era, so it requires huge effort by the user to become truly productive by todays standards. Trying to create layers upon layers of "friendlines" and eye candy is not going to solve the complexity.

I've always said that it's better to grasp Emacs with a vanilla config or a small starter kit and see if you can make it grow step by step in a journey that takes years.

vim is a similar rabbit hole, maybe less deep.

The real question is: can VS Code make you productive _enough_ in less time?

<comment><USER9> Pretty much, yeah, from what I've seen. Against the shockingly low ambient baseline of "editors that aren't Vim or Emacs", VS Code's highly usable OOTB experience and broad extension ecosystem are enough of an improvement to constitute a real win despite being so poor by comparison with a thoroughly evolved configuration of either of the Two True Editors.

I stick with Emacs because, now having invested more than a decade in learning to get the most out of it, I can do a lot of things in seconds that take VS Code users minutes or hours. But the converse is also true, and I think will only become more so. Especially in the realm of remote collaboration and mentorship, which has never been more important than it is today, VS Code does things that Emacs simply can't, and almost certainly never will.

That's fine, of course. That different tools should specialize in different things is perfectly reasonable, and I don't have the kind of emotional attachment to Emacs that would give me cause to be upset with its dwindling user share or its lack of broad appeal. It serves me very well, but it's not something I advocate, although of course I mentor those who take an interest.

I am looking at picking up VS Code, with suitably Emacs-esque keybindings, for the mentoring-in-programming aspect of my role. That's where pretty much everyone else is, or is going. And in that context, its less fluent and less extensible user interface is probably a boon, once I get over being frustrated by it. In the context of teaching someone less experienced, acting with the speed of thought is really best avoided; if you don't explain why you're doing what you're doing, or offer the chance for questions and discussion, essentially the entire point is lost.

<comment><USER10> > I can do a lot of things in seconds that take VS Code users minutes or > hours.

Out of curiosity could you provide some examples of some of these?

<comment><USER11> "Out of curiosity" = "I'm going to nitpick this to hell and back"

<comment><USER10> Ahh, that's not what I was going for. I'm actually just curious. I'm willing to give emacs a try, but it just seems like it has kind of a steep learning curve, so want some strong reasons to know if it's worthwhile. This was the best I could find googling: [https://www.reddit.com/r/emacs/comments/8h1cxa/any_long_time...](https://www.reddit.com/r/emacs/comments/8h1cxa/any_long_time_emacs_users_tried_vscode/)

<comment><USER9> I mean, a lot of it is just the kind of complex one-off text transformations that would normally require a throwaway script or program to express. (They do in Emacs too, but you can write it as inline Lisp forms in the replacement side of a PCRE find-and-replace, and not deal with any boilerplate.) Refactors and stuff like that all happen through LSP providers, just like in VS Code.

If you're looking for a strong reason to think Emacs is worthwhile as a totally new user, I'd point instead to Magit, an extremely powerful and comfortable git porcelain, and Org-mode, which is simply the most powerful and flexible single-user notetaking/outlining/live code notebook tool yet created. Those are the two Emacs features I see most often mentioned as the subject of sentences like "I don't use Emacs for anything else, but I do use it for X because nothing else comes close".

That said, as I mentioned above, I'm not really here to evangelize Emacs. It definitely does have a steep learning curve, enough so that unless you see a clear killer feature (in my case, TRAMP's transparent remote file editing, since I edited remote files a lot in those days), it's not likely to be worth the trouble.

<comment><USER12> This. After having fiddled around with Emacs over the weekend, having tried out Spacemacs and Doom and working through some tutorials, I concluded that I definitely won't replace VSCode with Emacs for coding any time soon. As a Git & PIM-Tool, it seems to be useful though.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> Does it need to be popular or need more users to become maintainers?

I use emacs because I can't imagine using anything else that has half the features and is harder to extend. I can't imagine why it needs to be popular. It's a programming environment that happens to have a text editor built in. That appeals to some folks but I can't imagine why someone interested in writing for publication would choose it over Scrivener or a word processor and why it's desirable to attract such users.

If I had a horse in the race I'd focus on the developer experience. Make it easier to extend, make the runtime faster (the native compilation stuff is super cool), better unicode support, alternate input methods, etc. If people want to use it for publishing it should be easy to write a package to cater to those users.

For me, a long time emacs user, I think the biggest concern I have is ensuring that the project is sustained by new developers.

<comment><USER14> Perhaps adding JavaScript to the list of languages that you can extend Emacs with would be a good start - [https://www.emacswiki.org/emacs/CategoryExtensionLanguage](https://www.emacswiki.org/emacs/CategoryExtensionLanguage)

<comment><USER15> Or, emacs in the browser. Popular editors like VS Code use monaco and now github has codespaces [1] which is running in the browser.

People live as much or more in the browser as the terminal these days, so bring the emacs sauce to where the people live. Maybe you could get some of the c compiled to web assembly, and the lisp would follow? It'd be neat to open a buffer to the page emacs lives in and start editing, call JS code, or embed emacs into a page as easily as monaco. Maybe the GUI components could be made out of HTML 5?

1\. [https://techcrunch.com/2020/05/06/github-gets-a-built-in- ide...](https://techcrunch.com/2020/05/06/github-gets-a-built-in-ide-with- codespaces-discussion-forums-and-more/)

PS. Rough sledding for Gitpod with this announcement.

<comment><USER16> Emacs in the browser, you say? _smug Willy Wonka face_

[http://www.ymacs.org/](http://www.ymacs.org/)

<comment><USER15> That's a cool project and a nice effort. It renders pretty well on my iPhone too. Not able to edit on the phone, but still.

I see some other good ideas here too that could maybe give emacs a fresh breath in the new world of IDEs in the browser/cloud.

</comment></comment></comment></comment></comment><comment><USER17> I hear a lot about the declining popularity of Emacs, but I always wonder how much it is overstating the case. As a tech enthusiast but (mostly) non- programmer, my perception has actually been that the "cool factor" of Emacs has been on the rise. Around 2011 or so, I hardly ever saw mention of it online. Now a day hardly go by on places like Reddit's "unixporn" board that someone doesn't post their slick setup with Emacs/Doom Emacs/Spacemacs on display.

I know that that Reddit board is sort of ridiculous and the jokes about it write themselves, but I nonetheless feel that Emacs has attained a certain counter-cultural "cool"/cachet in recent years that it lacked a decade ago. In my opinion, this is a good sign for its future, all things considered. These threads are always full of comments about how vscode has surpassed it, etc., but I don't think anything can change that--Emacs will ever truly satisfy those for whom vscode is presently the superior tool, and conversely, vscode is unlikely to satisfy the Emacs user.

Like vscode, Emacs is in every sense a practical tool; it is simply that it is practical in service of different needs. It is a practical tool for someone who takes active pleasure in the _cultivation_ of a practical tool, in the process of learning and discovery involved. Because this will never describe a majority of users, I don't think Emacs will ever capture a majority of developers or whatever, but it seems poised to continue to attract very dedicated ones who find the cultivation of a personal work environment in a ridiculously powerful 40-year-old program appealing in and of itself.

<comment><USER18> Anecdotally, I started learning Emacs a few months ago and am very happy with my decision. I first considered trying roughly 10 years ago, but didn't see the thriving package ecosystem I see today, starting with projects like Spacemacs and Doom. After some time trialing my options, I stuck with Spacemacs, and that choice saved me time in reaching my goal of transitioning my knowledge and project management to org-mode.

Even with training wheels, though, getting started wasn't simple. It's had a very choose-your-own-adventure feel to it. After some early thrashing, I've now found my favorite resources, have a decent sense of what's out there, and am even using org-mode to track my overall learning progress. It's become self-reinforcing.

With more modern tools getting better and better, I find it no surprise that VS Code and others are gaining market share, and that the Emacs user profile is becoming less diverse. But I think there will always be a place for a tool(box) as powerful and configurable as Emacs.

<comment><USER19> I've started learning Emacs a few weeks ago, and have had a similar experience as you. One different is that I considered going with Spacemacs / Doom but decided to take the route of starting from an empty init file and slowly building up from there (at least for now). I identify strongly with the feeling of thrashing; the wealth of different information and flexibility of the program itself can be overwhelming. Would you be willing to share some of your favorite resources (and why you chose them)? That would be immensely helpful for a beginner like me.

<comment><USER18> I think there's a lot to learn from starting from scratch, and it's something I hope to do too.

Gladly! I'll keep the list to what I've studied so far. Here goes: \- If you ever want to explore, say, Doom (Spacemacs is likely too bloated for someone who gravitates to a vanilla config), chemacs[1] is a nifty, simple profile switcher \- I think there's a lot of value in studying what they've done with their mnemonic keybinding systems (I love being able to narrow to an org-mode subtree and widen again with =, n= and =, N=, respectively, as but one of many examples) \- Sasha Chua is a good source, as she's very knowledgeable and put out a drawn 1-pager[2] on starting Emacs - it's geared towards standard Emacs keybindings \- Personally, I'm a huge fan of Evil-mode for Vim keybindings, as they're powerful and portable and I had basic familiarity with Vim before picking up Emacs \- I haven't found a rough edge in Evil-mode yet - it seems very refined \- Dired is worth getting a handle on early since any improvement in how you can navigate Emacs translates \- Magit is pure magic, and I now have my full ~/org under version control with what feels like near-0 overhead \- Seorenn makes mostly Spacemacs videos[3] and Zaiste Programming makes Doom videos[4], but I find them useful regardless of my config - you may just want to skip to the videos on packages that interest you \- If you haven't yet, choosing either Helm or Ivy is _huge_ \- Personally, I'm happy with helm in Spacemacs and I was happy with ivy when I used Doom - heck, even my friend is happy with Ido \- It's fun to explore more efficient ways of jumping around - the Avy package is very popular for this (check out `avy-goto-char-timer` in particular) \- Also, I'll note that I've been able to find a clean 1- or 2-pager reference card for every major package I've searched for

But, truly, the jackpot for me has been org-mode. At first, I used it as just another knowledge repo, like a more efficient (yet local and text-centric) version of Evernote. But, now, I'm working through the book _Getting Things Done_ and believe that there is no better tool on the planet than Emacs and org-mode for implementing the core and majority of that system. Regardless, having a specific implementation goal has aided my learning dramatically.

Specific to org-mode: \- I started with the Org-mode Compact Guide[5], which I'd study and practice during 20-30 minute sessions every other day or so - <USER3> moves fast and I was happy with my org-mode skill after only having worked through Chapter 2 \- However, perhaps the best way to start learning org-mode is Worg[6] \- Occasionally, I've found that the Compact Guide lacks an important command for my own workflow, so I'll usually go to the Org-mode Manual[7] itself \- When learning to configure Refiling, though, I found this[8] to be the best resource \- Finally, I'm a big fan of "org indent mode" \- it keeps Git diffs clean when changing indentation yet displays my contents appropriately indented

This is a lot, and I'm sure your path will be different than mine, but I hope you find some nuggets in there. Best of luck!

[1] [https://github.com/plexus/chemacs](https://github.com/plexus/chemacs) [2] [https://sachachua.com/blog/2013/05/how-to-learn-emacs-a- hand...](https://sachachua.com/blog/2013/05/how-to-learn-emacs-a-hand-drawn- one-pager-for-beginners/) [3] [https://www.youtube.com/playlist?list=PLPNohcoOBa5GGreLyc3nn...](https://www.youtube.com/playlist?list=PLPNohcoOBa5GGreLyc3nnSIGYB9UeVO_X) [4] [https://www.youtube.com/watch?v=rCMh7srOqvw&list=PLhXZp00uXB...](https://www.youtube.com/watch?v=rCMh7srOqvw&list=PLhXZp00uXBk4np17N39WvB80zgxlZfVwj) [5] [https://orgmode.org/guide/](https://orgmode.org/guide/) [6] [https://orgmode.org/worg/](https://orgmode.org/worg/) [7] [https://orgmode.org/org.html](https://orgmode.org/org.html) [8] [https://blog.aaronbieber.com/2017/03/19/organizing-notes- wit...](https://blog.aaronbieber.com/2017/03/19/organizing-notes-with- refile.html)

</comment></comment></comment></comment><comment><USER20> > "Perhaps we should implement a mode that puts cosmetics on Emacs so it will > appeal to those who judge by the surface of things."

I'm sorry to react to first quote, but as I kept reading I kept coming back to it. My thoughts on that : how you present yourself is how you want (and are going) to be judged.

In general I think Emacs has been user-hostile, as said here, just by its terminology. Nobody outside a minority of devs (a minority even among programmers) refers to Ctrl+c as C-c.

> Yes, make Emacs appealing and user friendly. But don't forget that a > masterful tool in the end requires mastery, which can't come for free.

And the old "I have suffered therefore the others have to suffer".

<comment><USER21> I don't think emacs is "user-hostile" on purpose. You have to keep in mind, it's nearly 45 years old. This is almost unprecedented in computing.

Today's users expect different things than users did in the 70s (who expected different things than users in the 80s, 90s, so on). Emacs has been relatively consistent through time, which has been a huge boon to emacs users. The tradeoff is against current user's intuitions -- for better or worse, emacs does not work like other popular software today.

Calling this "user-hostile" comes off somewhat entitled. Emacs developers in the 70s/80s/90s/00s simply didn't know enough about today's users to cater to us, even if they wanted to. That's hardly their fault.

So, todays way and the emacs way have diverged some, and it does take a bit of effort to learn. Not because emacs hates you! But because emacs is ancient. The (objective, non-stockholm-syndrome) reward for your efforts to understand it are a) mastery of a system useful enough to survive this long, and b) mastery of a system that isn't likely to change out from under you.

<comment><USER22> > You have to keep in mind, it's nearly 45 years old. This is almost > unprecedented in computing.

We can acknowledge Emacs's longevity without straying into unsupportable hyperbole. Emacs is nowhere close to unprecedented in its age and not remotely close to the oldest piece of software still in existence.

GNU Emacs is from 1984. It is a reimplementation of the earlier 1972 Emacs. This matters, since if you're including reimplementations then obviously Unix itself, which is used by many of us every day, it older. And if you start counting from 1984...that's not especially old.

<comment><USER21> Fair enough! But the point stands, no?

I pointed out emacs' age to note how users expectations of editors have evolved over that time. Certainly there is older software -- but is there any other user-facing software that has survived such a dramatically shifting landscape? _That_ is the part I find unprecedented (and the part relevant to GP).

<comment><USER23> > is there any other user-facing software that has survived such a > dramatically shifting landscape?

Yes. Microsoft Word, for example, is older than GNU Emacs.

</comment></comment></comment></comment></comment><comment><USER24> I use emacs and have for a really long time. Unfortunately, I don't recommend it to anyone because I think the costs of learning it outweigh the benefits.

When I read this article, I was surprised that my gripes don't overlap much with those listed in the article. I do really like the idea of "new user detection", which would take a user through a short configuration process if the .emacs file was missing.

I think my main gripe is async. I really love emacs for tramp, but there are so many operations that block working on all buffers while one buffer is waiting for i/o.

<comment><USER25> Choosing an editor like emacs or vi is a major decision which will have long- lasting effects. I love vi, and the homerow movement keys are now hard-wired into my brain, so much so that using 'normal' applications is noticeably frustrating. Sure, I can try to add plugins to everything, but that only goes so far and requires a lot of setup work on every new computer or VM. That said, the old school editors bring plenty to the table for programmers if you take the time to learn them well.

Honestly emacs sounds wonderful on many levels, but I learned vi first and I think that will keep me from ever switching. There's probably a vi-mode for emacs I guess... anyone have any comments on that?

<comment><USER26> I'm also a long time vim user. I basically cannot edit text without vim keybindings these days.

A few weeks back I decided to give emacs a third try, after installing it once a while ago and giving up, installing it again with spacemacs a bit later and giving up when I couldn't figure out what layer of that behemoth errors were coming from or how to fix them.

Anyway, I finally decided to give it another shot with vanilla, with the first thing to do being to get evil mode working (which is vim keybindings). Getting to that point was a struggle, honestly. I felt handicapped without vim bindings, and I ran into some errors downloading packages after I added MELPA to my .emacs file. After an hour or two, I managed to get evil mode going, and I guess just the little bit of familiarity in what was otherwise a VERY overwhelming and unfamiliar experience made everything feel much easier.

Getting to where it was easy to install and see the effects of new plugins one at a time rather than getting the massive overload of spacemacs was super helpful. It made the learning curve smoother for sure.

I mostly did all of this because I wanted to try org mode, and honestly that has been amazing. It's a very very good way of taking notes and tracking tasks. I'll probably spend some time next time I'm feeling like tinkering trying to get it more like an IDE, but for now I'm happy just with org mode.

<comment><USER27> That's how I settled things down finally, Emacs for org-mode and magit (actually spacemacs) synced with all my devices with syncthing, on mobile I use orgzly, and everything is under version control. I use Vim for everything else.

</comment></comment></comment></comment><comment><USER28> I've used emacs for maybe 18 months solid. I never found it had a single feature that my other editors didn't have (not saying it doesn't, just staying I didn't run into them).

My other editors can be extended via scripts. My other editors (mostly) have keyboard macros, repeat, etc.. My other editors can be used efficiently keyboard only. My other editors debug various languages. My other editors open shells in the editor. I don't care about org mode, I care about editing code.

Conversely many other editors do their best to be dev env aware, reading/understanding/integrating various language environment project files, which was never something I found in emacs (maybe it's all been added since I my emacs times)

About the only thing I still would consider using emacs for is editing in a shell remotely but (a) usually it's not already installed and (b) usually I'm not editing anything serious remotely.

What's special about emacs? What am I missing that's not in other editors?

<comment><USER29> Emacs is not an editor, it is rapidly-programmable-at-runtime-evolvable software that is designed to:

\+ Help you realize how _you_ best deal with information.

\+ Help you manifest your realization through _rapidly_ molding Emacs into your conceived model.

It is also the closest thing we have today to the Lisp Machine paradigm. I wrote this earlier today:

      You'll get the most out of Emacs if you treat it as an
      investment and put in the time to learn at least some Emacs
      Lisp so that you can confidently explore and customize the
      rest of the system. You don't need to become an expert
      overnight, just learn enough to navigate the system (which
      is self-documenting and geared towards helping you perform
      that navigation).

Yes, it may feel weird or out of touch with contemporary aesthetics but that's really because it doesn't come with strong, tunnel-like notions of _how you should think_ and _how you should work_.

It is not easy today to come to terms with a tool that's simply designed to help you craft a computing experience, since we've been so conditioned to expect somebody else's model be there from the beginning:

[https://xristos.sdf.org/why-emacs.txt](https://xristos.sdf.org/why-emacs.txt)

<comment><USER30> At what point does this get in the way of your programming? If there's always more to learn about the tool, I think that would bother me. I would like to like emacs, but the couple times I tried it it gets in the way because I don't know it well enough. Vim seems more appealing because there is less to know up-front, but it is still extensible

<comment><USER16> At the point where you find yourself dinking with Emacs and making excuses to yak shave instead of getting your work done -- which, given that it's Emacs and makes most other tools seem positively stone-knives-and-bearskins by comparison, is in practice a quite tempting trap to fall into.

The best way to approach things is incrementally. Find some pain point in your current workflow and write a little bit of Elisp to automate the painful bits. Let's say you're running manual UI tests and then eyeball-grepping the logs in your backend. "But nobody does that!" you say. "Why would anybody do that?" Heh. You'd be surprised. Anyhoo, thr crank has to be turned on a prod deploy by COB Friday and you've got no time to investigate Nightwatch or the other UI-testing libraries out there, let alone integrate them with a log watcher.

Thankfully you're an Emacs user! So you write a little Elisp to start the back end, capture its output in a buffer, and count the number of occurrences of the log cookie that represents a successful (or failed) row insert, etc. You haven't automated your whole process, but you've automated part of it, and that's saved you considerable pain. And it took maybe half a page of Lisp, if that.

Recently I was confronted with an ancient web service whose only integration test process was "manually hit the endpoints with Postman, then check to make sure the records hit the database". So I wrote Emacs Lisp code to send the requests, run the queries, and even manage the Docker container where the service lived. This let me run the whole process much faster with a few M-x commands. It was nothing fancy, either, I just wrote code to spin up curl, Docker, and SQL*Plus and capture and examine their output, sort of using Emacs as a powerful full-screen shell. Rather than get in my way, it became a versatile tool I could apply to the task to get things done much faster.

Again, this is the difference between an extensible editor and a completely malleable one. VSCode, JetBrains, or Eclipse cannot be extended as incrementally and on-the-fly as Emacs.

<comment><USER30> I can understand that. I just like to tinker too much :). Going at it with a goal in mind would be a good idea

</comment></comment></comment></comment></comment><comment><USER31> A shame Stallman put the kibosh on QT quickly. Is he planning on there being a GPLv4? Not in the "leaving that option open for the future" kind of planning, but more, "A need has been identified that can't be met by v3, it's time to start working on v4." Because if they truly want a cross platform visual interface, AFAICT, QT is the closest you're going to get, and IMO, is the best means of doing so. Every QT app I've seen has looked and acted a lot closer to a native app on Windows and Mac than anything that ever came out of GTK or other GUI toolkits. And I don't understand why GTK doesn't have the same issues. It's not a GNU project AFAIK. It can't be a GPL vs LGPL thing, because QT is also available under LGPL. Is Stallman perhaps just stuck on the fact that QT was once not available under a free license?

<comment><USER32> > And I don't understand why GTK doesn't have the same issues. It's not a GNU > project AFAIK.

Iirc GTK was born out Gnome, and Gnome was born as a FSF-project.

<comment><USER31> Okay, but even if GTK is a GNU project or a FSF project, why does that mean it qualifies for being part of a future GPLv4 licensed EMACS, and QT does not? Both are available under the LGPL. I wonder if Stallman expects that a GPLv4 would likely or definitely be incompatible with LGPL3. I don't think it's because the LGPL version would be bumped if a v4 came out; GTK is still on LGPLv2.1

<comment><USER33> It is because of the license. GTK's license is LGPLv2.1 or later[0]. The important part is later, It means you can update it automatically to any later version, especially if the new license is not compatible with the previous version. Qt does not offer their software with a similar license.

[0]: [https://gitlab.gnome.org/GNOME/gtk/-/tree/master#licensing-t...](https://gitlab.gnome.org/GNOME/gtk/-/tree/master#licensing- terms)

</comment></comment></comment></comment><comment><USER34> Emacs might never catch up to Visual Studio Code, which is actively funded by Microsoft, but intuitively, it seems like Emacs ought to be able to catch up to Vim. It's always been weird writing Emacs extensions in ELisp, but it's not like Vimscript is a top-tier language. Emacs is hard to learn, but so's Vim.

I think it comes down to performance, especially startup time. Emacs developers have never cared much about it, and I think that's connected to its reputation for "bloat."

The death knell rang when Linux distros stopped distributing Emacs by default; Emacs isn't installed by default on Ubuntu or Fedora, say nothing of macOS or the Windows Subsystem for Linux.

If I were working on Emacs, my #1 goal would be to beat Vim on startup time-- to get the first page of text to show up faster than Vim--and my #2 goal would be to convince the major distros to include Emacs by default.

Sadly, I don't think any of this will happen. Stallman is too far out of touch, not just with newbies, but even with active users of Emacs. As the article points out, he's never even used Org mode! [https://lwn.net/ml/emacs- email@example.com...](https://lwn.net/ml/emacs- firstname.lastname@example.com/)

EDIT: I know you can do some non-default techniques to make Emacs start faster. But that won't get Emacs to be installed by default on popular distros. Installing more plugins won't make Emacs the quickest and easiest way to edit a file.

<comment><USER35> Vim might be hard, but besides jokes about "how to quit it", it makes much more sense than Emacs.

Emacs key combinations are weird. Discoverability is low. Even Vim will now tell you how to quit if you Ctrl-C it.

Meanwhile I have opened Emacs and I'm trying to quit it (spoiler: Ctrl-x Ctrl-c). Some things are actually interesting and it tries to help at first but then it goes back quickly into emacs-babble that doesn't help much.

The case for vim is simple: a quick editing of a file when you might not have a window manager up or on a terminal.

I don't see many reasons to learn Emacs when VSC, Atom or other editors exist.

<comment><USER36> > Vim might be hard, but [...] it makes much more sense than Emacs.

Counter-point: I think emacs makes much more sense. If you start it, you can navigate a file by clicking in places. It is a GUI application, whereas I think vim is just a terminal program by default?

Emacs has a little built in tutorial (Ctrl+h t) and is quite discoverable (type Ctrl+h ? and it shows you a lot of commands you can use to find out about what functions a chord invokes or how to invoke a function with a key cord). With helm you just type a part of a function and it gives you a list of suggestions.

Within programming languages I think auto-completion is a _must-have_ for discoverability. Otherwise I have to constantly look up stuff in the documentation. And for that company-mode is really nice, I don't know about the vim side of it but I think something like that goes against the philosophy of vim as I understand it?

To me, modal editing didn't make much sense in the beginning and for emacs the learning curve seemed less steep, so that's what I went with in the end. But clearly it must be good somehow, because so many people use and love vim! It's just not for me I guess.

<comment><USER35> Yes, in the XEmacs case it is the case, not necessarily when you're using it like VIM

(There are gui versions of VIM as well but it feels weird)

</comment></comment></comment></comment><comment><USER37> It seems that if vim is so much more popular than emacs, old fashionedness doesn't necessarily make an editor less popular.

If one believes that emacs would be more popular if it were more like some other editor that is more popular then being more like vim would make emacs more popular. Evil has existed for a long time but vim is still more popular. As much as emacs can be like vim, people still feel vim is better at being vim.

If emacs was more like VS code, would people want to use it for that reason? It seems like VS Code would always be better at being like VS Code than emacs.

Emacs has a loyal following, conceivably of millions of users? It also attracts new users who like things about it. There are packages for most languages, even very obscure ones. Being less popular than vim doesn't seem to make emacs less useful or keep new people from picking it up. It seems like emacs is a good thing according to many people as is and if its developers want to make users happy, looking at what people use emacs for and making it do that better would probably be a good idea. Making it more like other things that already exist doesn't make as much sense to me really.

I guess I don't really understand why it is important to be most popular as long as something is useful with a strong user and developer base.

<comment><USER38> Agreed. Emacs and Vim basically try to do the same thing with two very different approaches, and both can fit well depending on the use-case. I also get why many prefer VS Code, because spending hours to learn and configure a program just for text editing is not universally appealing. But other people just want that configurability.

> Evil has existed for a long time but vim is still more popular.

Because the behaviour isn't identical(it even has default settings that intentionally deviate!), because it isn't complete(it doesn't affect any other mode), but most importantly for me because Emacs cannot fully match Vim's keybinding functionality. I broke my Emacs configuration a dozen times before realising that.

I am glad I tried out Emacs as a Vim user though, it led to a couple improvements of my Vim configuration and I learned a couple new things.

</comment></comment><comment><USER39> I'm not an Emacs user, but with all kinds of software like this, I find that the strengths lie not in what makes it popular but what makes it lasting. If too much is changed in Emacs, scores of users will cry havoc and switch to XEmacs (or something) and it will become even less popular.

Emacs has a stable core user base and as far as I can tell, it's recently getting some traction among a new generation who are exactly the kind of users that would likely jump ship as soon as a lot of "modernization" started happening. If they wanted something "modern", they wouldn't opt for Emacs in the first place. It's not like there's a lack of choice: IDE:s and editors adhering to current trends and concepts within UI/UX design are plentiful. They have sought out Emacs because it is uniquely Emacs and not yet another Sublime/VS Code/Atom.

Editors aren't exactly comparable to desktop environments, but when Gnome 3 was conceived for similar reasons of following design trends and thinking afresh, we suddenly also had Cinnamon, MATE and Budgie instead of just KDE and Gnome. Not that I mind diversity, but it's a fine example of alienating a user base. Now, consider how conservative an Emacs user of today probably is.

I find that one of the few things I still truly enjoy about computers is that there is stubborn software left for stubborn people to use. Slackware, Emacs, fvwm, xterm... Familiarity, not innovation. That's worth something, too.

<comment><USER40> > it's recently getting some traction among a new generation

Where can I learn more about this? If I teach my kids emacs will they not be the only ones among their peers who use it?

<comment><USER39> As someone else pointed out elsewhere in this thread, check out /r/unixporn. Kids today with their tiling wm:s and esoteric editors, eh?

</comment></comment></comment><comment><USER41> Outside of the text editor, I think native emacs keybindings like (C-n, C-p, C-a, C-e, C-k) on OSX are great and I hope they never get rid of them.

<comment><USER42> Please never get rid of this

As a user of these key binding in both Emacs and macOS, it'd be worse than cutting off an arm if this went away

<comment><USER43> Or next-paragraph/last-paragraph movement.

Or all movement combined with prefixes. I regularly do

      C-u C-u C-p

to jump sixteen lines backwards. Or add another prefix and it's 64 lines.

Separately, macros, yea! Macros with regexes FTW! The counter you can use in macros - occasionally very useful! M-x occur! Dired which can search a whole directory tree of file contents for a regexp! So much more.

Only thing worse than emacs interface is not having emacs at all.

</comment></comment></comment><comment><USER44> Emacs is not an editor, is a personal travel to find and build your ultimate editor through the years, a solution that will work forever but only for you.

Yes, is the most powerful tool that ever existed, a beautiful monstrosity, no other editor will let you cherry-picking git commits, handle your agenda, export to PDF, measure the time for a cup of tea and estimate the new project costs. In some point Emacs becomes a part of yourself. Yes it will be loved and tamed only for us, the weirdos, and that is ok.

In 1996 all my friends were asking me why I installed and struggled so many hours with that thing called Linux, when Windows was so easy. "Nobody uses Linux", they told me. Well, Linux made me very good with DevOps tasks, and I finally learned what software is about when I discovered eLisp.

As many other things in this world, Emacs is not for all people.

<comment><USER45> Out of curiosity, what is software about to you and how does elisp teach you?

</comment></comment><comment><USER46> Please. Emacs will never be popular. Emacs does not need to be popular. Making it popular will require dumbing it down to the level of VS Code. It's doing just fine as it is, please leave it alone.

Edit: I mean, it's a complex, sophisticated, hard-to-master instrument, kind of like Organ. If you feel that popularity of your instrument matters above all (which is perfectly fine) -- just get yourself a Kazoo.

</comment><comment><USER47> Oddly, I think you will make Emacs appealing to users when you start asserting it is appealing to users. Few changes really needed. Just stop intimidating people before they get involved.

<comment><USER48> My experience with Emacs has been a steady upward trajectory, gaining understanding and access to functionality. I now use CIDER and TRAMP every working day, and no true equivalent exists for any other editor (though many are catching up to CIDER, due to Clojure being the better lisp!).

The biggest problems with Emacs, to me, are the rendering performance, the lack of sufficient threading, the default keyboard-accessible windowing commands, and Elisp being unergonomic and sad.

The course I'd chart for an ideal Emacs would be rendering with something like Alacritty†, some default windowing commands similar to tmux, and phasing out Elisp in favour of a Clojure dialect; the last bit would help a lot with introducing some basic sources of concurrency.

† Plus smooth scrolling surfaces, since a text editor generally does not have enough surfaces that the memory overhead of tiled surfaces is a serious issue like it is for general-purpose renderers like web browsers.

<comment><USER49> As someone who claims to be using "the better lisp" what is it about elisp that you find "unergonimic and sad"? Genuinely curious.

<comment><USER48> At least when I've written elisp, the default datastructures have involved a lot of work to construct and manipulate, and when you do it right, the ones you've chosen for convenience may perform so poorly that you have to go back and change them to get your program to complete in time.

Namespaces for vars and functions being not a language feature is inconvenient. Unless you are using fakespace or intern-symbol (it seems hardly anyone does), every symbol in your program needs to include its namespace information in order to avoid it being accidentally invoked by somebody else, or accidentally convincing somebody that it's part of the base distribution.

In Clojure, it's many little things:

Keywords are callable, allowing you to evaluate a keyword on an associative collection like hash-map, or traverse, in an obvious and intuitive way, into a nested associative structure with the threading macros "->" and "->>".

The default data structures are fast (for what they are) and hard to misuse: unless you ask politely, you are not going to mutate something your function was passed passed without noticing. seq, the interface for sequences (vectors, lists, pairs from an associative structure), pairs well with destructuring in let and macros/syntax that does binding.

Things like 'let' don't use more parentheses than necessary, which has a greater impact on readability than you'd think. The use of vector syntax for bindings rather than list syntax adds a little bit of syntactic texture that makes reading programs more ergonomic.

I think Clojure may not be as unfamiliar as it seems at first to a person who's written other lisps before, but I have yet to meet somebody who prefers the experience of writing Scheme or Common Lisp to Clojure; nor anyone who prefers Elisp to Common Lisp.

<comment><USER49> You should check dash[1]. It adds a lot of those "many little things" from Clojure (such as ->, and ->>, and let) to elisp.

[1][https://github.com/magnars/dash.el](https://github.com/magnars/dash.el)

</comment></comment></comment></comment></comment><comment><USER50> I wish Vim users and Emacs users would unite to improve Spacemacs. It's really a great idea IMO, have the editing power of Vim with the flexibility and elegance of the Emacs environment.

Unfortunately when I tried Spacemacs (coming from Emacs) I kept bumping on rough edges with vim command emulation which ended up with me switching directly to the real vim. It's been about a year now and while I still think I was right to finally make the switch to modal editing, vim feels like a clunky and hacky environment compared to the power of Emacs.

<comment><USER51> Vim and Emacs have too many philosophical differences for this to work. For example, emacs doesn't have a fixed concept of what a paragraph should be. Instead, it leaves that up to the major mode. This is fundamentally incompatible with vim's paragraph motions which are determined by empty lines and remain the same regardless of file type.

As a very long-time Vim user, I prefer that my editing commands be predictable since I type them with muscle memory (faster than ordinary conscious thought). Having them vary from file to file based on file type (the Emacs way) throws me off completely and makes the editor feel untrustworthy, like a horse that's liable to kick or throw its rider. Vim feels like a complete set of high quality, manual woodworking tools.

<comment><USER50> Interesting viewpoint, but aren't there enough differences between programing languages to warrant mapping these concepts slightly?

Clearly my Emacs origins show here, because not having simple built-in motions to select "a function" or "a class" feels like a big limitation to me. I actually have a bunch of ad-hoc bindings for that. I also seldom use paragraph motion while coding simply because it doesn't really make a lot of sense to me. I think about code in lines or blocks, not paragraphs that is a rather weird concept when it comes to code. The fact that you can't easily add new motions to vim is a big limitation for me.

>Vim feels like a complete set of high quality, manual woodworking tools.

They're mostly reliable and predictable, I agree with that. High quality I'm not sure. The fact that the undo tree is effectively unusable without 3rd party plugin is weird. Tabs are at the same time over-engineered and under- featured. Nobody seems to really knows what they're for or how to use them (just make a quick search online for "vim tabs").

They're like Emacs frames except that you can't actually use them like a separate frame on a different screen. And you can't have them use a different working directories easily so they're useless to open two projects side-by- side. Some people coming from editors that open files in individual tab (an anti-pattern IMO, but that's a different discussion) expect them to work that way, but it turns out that they can't really do that either. Why even bother?

You also need plugins to do very basic coding stuff like run "make" in the background without being locked out of editing. Which wouldn't be too bad if Vim's internal API made it easy to make Vim plugins work seamlessly like native code, but in practice all the plugins have tested needed to be super intrusive to offer basic functionality (like remapping literally half the keyboard to slightly tweak the kill/yank behavior) and it ends up breaking left and right in weird and unexpected ways.

The visual feedback for commands is atrocious. Spacemacs' genius is that when you start typing commands it shows you what you can press next and what it does. You effectively navigate the bindings like menus, and you have this positive feedback loop where you memorize the bindings by using them. Sometimes I start typing a command in vim and I think I made a typo but I can't know because I have zero feedback on the current state of vim. Emacs almost always tells you what it's waiting for in the mode-line.

Why does ":bdelete" also kill the window it's in, except when there's only one window left? Since elsewhere there's no 1:1 relation between windows and buffers, you'd expect to get the next buffer in the stack (that's what Emacs does in this situation, and that's what Vim does when you have one window left). Window and buffer handling is hard but Emacs is vastly more configurable and works better out of the box in my experience.

I also often get performance issues that I don't remember ever getting in Emacs which is fairly ironic given that Vim is supposed to be the "lean" one.

<comment><USER51> _Clearly my Emacs origins show here_

I think so. The Emacs philosophy is essentially to treat the editor like a highly-customizable IDE. I use Vim only because I want a Vi that has a few quality-of-life tweaks here and there (the undo tree works fine for me without any plugins, I just use g- and g+). I don't use the vast majority of what was added. The core of what I want was created by Bill Joy back in the 70s.

I want a text editor that works the same whether I'm editing a C source code file or a text file that happens to have some C pasted into it or a configuration file or a file that looks superficially like C but happens to be a different language. I'm not interested in an IDE. I would prefer that most of those language-specific tools be separate programs that I can invoke by shelling out.

Performance issues in Vim are usually caused by various autocompletion engines, none of which I use. I like Vim's built-in completion which is very simple and predictable (fitting the theme), invoked using C-x in insert mode.

</comment></comment></comment></comment><comment><USER52> Am surprised that a starting point has not been highlighted earlier: the onboarding. To get news users using your product, you have to lower the friction. By making great docs and the environment easy to setup to get started, you can make this process easier.

Why not start with that?

I have always felt that the initial config of emacs has been painful.

</comment><comment><USER53> I see this "Emacs is terrible, my (insert currently hyped IDE/editor) is much better" mantra every few years. These days, it is VSCode, few years ago it was atom/pycharm/intellij, before that was anything on Eclipse platform... Yet, I need to see status of any these after 40 years.

Emacs is like a turtle - it isn't flashy and trendy, looks weird and old, but is still going steadily and strongly. And I bet you'll be able to run your configuration 10 years ago, for the next 20 years without any problems.

I'd say, if you don't like Emacs, use something else. Usually everyone returns back to either Emacs, Vi(m) or Sam at some point. True hackers will go to ed - ed is the standard text editor after all :)

</comment><comment><USER54> I think a large part of the issue is the default keybindings (the GUI is also bad, but I think it's bad in a way that's not going to be impossible to fix without screaming from people who like what's already there). It's truly only lacking a decent text editor.

This isn't to say that the keybindings never made sense; in the stage of computing before X, where Space Cadet-like keyboards were common, it was more than fine.

Currently, though? Entirely different era of computing.

Imagine you're walking in with no clue. You haven't heard of any of the memes, someone just recommended you a text editor. "It's really good! You'll be more productive!" You have no idea what in the world evil is, or why you would ever want it.

You launch the tutorial/tour/whatever it's called and immediately it yells at you to use C-v to jump to the next page. And then M-v to go backwards! If you're a normal user, your response is probably something along the lines of, "Like, why?"

Off to a good start, breaking the most universal keybinding across modern operating systems in the strangest way possible, and not only that, but also breaking one of the biggest implicit rules of keybindings.

You read a little bit more and eventually get to cursor control. Wow, somehow they managed to pick the only possible thing less intuitive than 'hjkl'! Not only that, but it's not even _consistently_ unintuitive!

And that's not even getting into the obvious problems that come with the placement of M and C on modern keyboards.

There are a few solutions to this, obviously, but good luck trying to find a solution that isn't universally-hated.

You could make evil the default. Controversial and only slightly helps the barrier to entry.

You could make it like the Web's model of text-editing but with quality-of- life enhancements. I think this one is probably the winner. It's definitely why Sublime/VSC/Atom won, past everything else.

The Turbo C/Wordstar approach was cool, but has no mind-share today.

You could try something new, I guess? This is dangerous territory, though.

I have no idea what the solution is, but the problem(s) seem obvious. I say this all as a person who really _likes_ Emacs. I even still have most commands memorized despite not having touched it for years now!

<comment><USER55> > You launch the tutorial/tour/whatever it's called and immediately it yells > at you to use C-v to jump to the next page. And then M-v to go backwards! If > you're a normal user, your response is probably something along the lines > of, "Like, why?"

The hardcore emacs users think these keys are better. And don't want to change them, because then they had to rewrite the whole manual which uses these keys.

The user don't have to use these keys, though, so there is no point in the tutorial starting with them.

<comment><USER56> Right? And yet I just typed 'emacs tutorial' into DDG, and the first three results all hit you right away with descriptions of keys that don't physically exist on a modern keyboard.

[https://www.gnu.org/software/emacs/tour/](https://www.gnu.org/software/emacs/tour/)

[http://www.jesshamrick.com/2012/09/10/absolute-beginners- gui...](http://www.jesshamrick.com/2012/09/10/absolute-beginners-guide-to- emacs/)

[https://www2.lib.uchicago.edu/keith/tcl-course/emacs- tutoria...](https://www2.lib.uchicago.edu/keith/tcl-course/emacs- tutorial.html)

I've never tried emacs in large part because I've been convinced over the years that the various combinations of keys I would need to memorize are too complicated. I just did that search thinking that maybe I'd been mis- remembering, but no, that's still the impression that I have.

<comment><USER57> I'm curious, how do you remember key combinations in other IDEs? I learned Vim, it was tough, but I remember a handful of commands I use all the time. And used Vim mode when available in IDEs when available. Spent a few years with VS Code, but I could never remember certain keys to navigate between panels for example. But the F1 key is great though. For w/e reason, I tried Emacs with evil-mode. I don't have to remember that many new keys I think, but a few of course. 'which-key' and M-x enables me to search for _all_ commands, and I can also see the key combinations if I need to learn it later. In VS Code I try the F1 key, but if I could not find it there, I would grab the mouse and click around in menus looking for key combinations. Or go into settings and try to find w/e I was looking for. Of course, in Emacs I have spent hours setting things up, searching on the internet for clues on how to get something working as expected.

Perhaps I am doing something non-optimal in my process. Curious how others learn/get productive in their respective IDEs.

<comment><USER56> In most IDEs, they're the same key combos I use in non-IDE products. I'm on a Mac, so Cmd-X, Cmd-C, and Cmd-V work pretty much everywhere. They even work at a terminal prompt, and the latter two work in vi.

I did learn vi years ago, but I'm sure I still don't tap but 10% of its power, despite using it daily, precisely because the key combinations seem arcane to me.

</comment></comment></comment></comment></comment><comment><USER58> Who cares about popularity? It often brings more trouble than anything. Emacs is a gem and will probably stay like that for decades to come.

The only thing I wonder about is how it is possible that Stallman seems to have never heard about org-mode which is one of the main reasons I use Emacs and I don't think there exists anything that even comes close.

I manage my todos with org-mode, generate chord sheets of my songs and even produce my website from org files.

<comment><USER59> I don't think Stallman writes code anymore. It's surprising that he doesn't use org-mode for other, life organization issues, though.

</comment></comment><comment><USER60> This is a super dumb example, but I hate that scrolling is tied to cursor. Like if I'm _gasp_ using the mouse to scroll through a file in emacs, the cursor has to stay in the viewport. If I scroll past the viewport, the cursor moves to the viewport. In IntelliJ (which has such good emacs keybindings I can use it for a lot of my work), the opposite is true: when I scroll away from my cursor, it stays there and when I start typing again, my viewport moves __to my cursor __not vice versa.

It's a small thing but it shows emacs' age. When emacs was written, GUI cursors weren't a thing. Scrolling wasn't a thing. Of course the cursor and the viewport would be connected. There wasn't any other way to move the viewport. Basically emacs needs to be somewhat GUI native.

Emacs should also be more discoverable. It's hard to incrementally learn key commands. I hate that the default for M-x is just a blank line. It's really intimidating. Having some sort of fuzzy search/history like Helm makes M-x so much easier to use.

Basically emacs needs to get UI and UX people to give it a refresh. Nothing outlandish, just get it into the 21st century.

<comment><USER61> It's because scrolling doesn't actually make sense in emacs or vim, if you've put some time into learning how to use them.

In vim, for example, you would be much better off navigating with the keyboard than the mouse. You can leave bookmarks all over the file and jump between them with 2 keystrokes. There are also a multitude of navigation controls ({, }, gg, G, etc.) that save you the time of moving your hand in between your mouse and keyboard.

If you want to use your mouse, maybe vim/emacs aren't for you -- sublime or vs code will probably serve you better.

<comment><USER62> I'm genuinely curious: do you not read through code from top to bottom? That's a very common thing that I do, and using the mouse is a comfortable way of accomplishing it.

<comment><USER63> If you want to go to the next page (screen) of code, isn't the keyboard just as comfortable? If you want to go down until you find the thing you're looking for, wouldn't a search using the keyboard be potentially more comfortable?

<comment><USER62> I like how I can control the rate at which I scroll with the mouse more easily than with the keyboard. It's a more intuitive movement that I can adjust to match the speed of my reading.

<comment><USER63> The point is that reading code from top to bottom is not a reason to need or prefer a mouse. Other people prefer using a keyboard and find moving through pages more intuitive than scrolling.

<comment><USER64> Different people have different preferences, so clearly it is a reason to prefer a mouse.

I don't use my mouse with Emacs, but I'm not going to tell someone else they're wrong for wanting to. I'm beginning to see why people feel the Emacs community is less-than-welcoming.

<comment><USER63> Of course different people have different preferences. I don't tell anybody that the way they prefer is wrong! I don't say there is a reason to prefer the keyboard either. But being what it is doesn't make Emacs broken. You can definitely read code from top to bottom on it.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER65> I've been fortunate to be able to use Emacs for the last 35 years or so. If memory serves (and more and more, it doesn't) I started with Gosmacs and moved to GNU Emacs sometime around 1986 or so.

At 60 years old, I don't have the enthusiasm or the time to learn a new editor. And I'm having too much fun programming in Lisp.

</comment><comment><USER66> I love emacs because it's fully programmable. This flexibility comes at a cost though, i.e. the time invested making the environment mine; exactly how I want it to be. It's like a sandbox for text based work on a computer.

Not everyone is willing to invest this time and therefore IMO it won't be a very popular environment for most users. I don't blame them, everyone's needs and priorities in life are different.

<comment><USER67> It's the ultimate yak shaver ;-)

Or you could start with a popular .emacs.d (I use Doom Emacs), tweak a few things, and tell yourself "I don't need to modify yet another key binding" a hundred times.

</comment></comment><comment><USER68> Popularity is more of a marketing problem than an editor problem.

At the same time, if we compare emacs to vscode, vscode simply requires less configuration to get going. Given how much tooling exists in the javascript ecosystem, I think having a few plugins "just work" goes a long way.

Asking users to configure emacs from scratch to have a reasonable editing experience in their programming language of their choice is a lot. I think configurations like doom or spacemacs do a lot for this problem, but it really comes down to marketing.

<comment><USER55> > if we compare emacs to vscode, vscode simply requires less configuration to > get going

True, but then why do more people uses Vim than Emacs? Is it becase it's installed on servers and stuff?

I wonder what percent of desktop programmers use vim or emacs who don't need to do devops.

<comment><USER49> Where I work nearly everyone uses Vim. We work in less popular languages that new kids on the block (VSC, Atom) don't really support. It really either Vim or Emacs. I think most people choose Vim because it is the default "Terminal based Editor" in most peoples minds.

</comment></comment></comment><comment><USER69> Well, spacemacs is an awesome intro for new users, which makes it cool, useful and quickly configurable.

Tried to use Emacs for data analysis in Python, because I write lots of docs in org and client project status/tasks report page is also generated from my org file. But the problem is proper support of repl in python. We got number of packages but none really solves my problem to have a proper analytics workflow.

P.S. I also write Clojure and Emacs it surely the go-to environment! Actually, I got into Emacs due to Clojure back in 2014.

\- Spacemacs for all the bells and whistles

\- Emacs Prelude for simple base

\- Doom Emacs is another beast, though.

P.S. What might make it much more accessible I think is builtin project structure view such as Treemacs. Also, let's not forget that Most of the world do use Windows and Emacs has a poor support for this platform.

\- The problem with VSCode, Atom and alikes are just absolutely inconsistent keybindings, half-baked packages and honestly I don't really want to write code in a browser. It's like a flashy smartphone - does everything but few things well. Hence my favourite tools for coding are produced by JetBrains - PyCharm and IntelliJ. These tools do also have their keyboard inconsistency issues, but it is what it is.

Happy Hacking!

</comment><comment><USER70> For me, I've recently started using Emacs solely due to wanting to try out rust-analyzer¹ (not touching Visual Studio Code since it uses Electron), and I'm really enjoying how insanely customizable Emacs is! The ecosystem around Emacs looks great too, with quite a few packages I´m interested in trying (like Magit²).

――――――

¹ — [https://rust-analyzer.github.io/blog/2020/04/20/first- releas...](https://rust-analyzer.github.io/blog/2020/04/20/first-release.html)

² — [https://magit.vc/](https://magit.vc/)

<comment><USER71> I cannot possibly encourage you more to check out magit. It is unbelievably good. I always share this demo with people to show off just a tiny portion of what it's capable of doing

[https://www.youtube.com/watch?v=rzQEIRRJ2T0](https://www.youtube.com/watch?v=rzQEIRRJ2T0)

My skills with git have gotten better after using magit, too, because it brings the power of git to the surface. It's a really fantastic git porcelain and the fact that it is deeply integrated into Emacs just makes it absolutely second to none.

Magit is easily one of my favorite pieces of software and I will leap at the chance to sing its praises.

</comment></comment><comment><USER72> I think licensing is not the problem, why nobody installs emacs anymore. It is initial setup. Where can I get a good code highlighter for all my code. Integration into obscure ide's compilers like iar. A workflow showing me easily what I changed, which files to check into git. A nice git overview of file history thanks to extensions. where can I get all this easily. One click and have a dark theme. Also easily customizable shortcuts. Manpower behind the editor for many changes and improvements. I mean who pumps out new versions every month.

I would say vs code does all that and while using an easy to overcome entry bar. And I am much more productive even than in native ide's for embedded development. Like iar eclipse or Segger.

The only thing I would want to try is using the org mode in emacs for nice todo handling. But else I see no appeal in emacs. It is just ugly, more concerned about it's license instead of just saying, this is free software just contribute and we will improve by using everything we can.

</comment><comment><USER73> I was about to jump ship to VSCode, but lsp-mode (despite minor hiccups) has extended my Emacs' expiration date.

So if I almost gave up, after having lived in Emacs for the last 12 years, can we really expect much popularity with those that are new to computing?

In 2020, Emacs is mostly just for people that love to build or customize their tools, or for folks that want a better Vim (i.e. Doom Emacs). And to customize Emacs you have to have a basic understanding of modes, hooks, keymaps, etc -- as well as at least rudimentary knowledge of elisp. Getting good at that stuff is a multi-year-long process. Emacs will never be "popular" for the same reason that if you want to have a fun night with friends, (statistically) chances are you'll choose to play Rock Band as opposed to learning real instruments. But as is the case with many niche and challenging things, it's hella fun and rewarding once you've spent a few years doing it.

</comment><comment><USER74> If rms doesn't understand org-mode, that seems to be pretty indicative of what the real problems underlying emacs' lack of popularity are.

I suspect that org-mode is responsible for more people using emacs than any other package by a large margin. Not understanding org mode suggests to me that rms is no longer on the same page as most of the users.

I know there's a lot of other good stuff in emacs, but org-mode seems to be particularly key.

</comment><comment> dan-robertson I feel like I've noticed an increase in the popularity of emacs online in the last 10 years or so. Or perhaps just a waning of vim zealotry. I'm pretty sure I used to see quite vim-related posts on hn but I don't really see them anymore, whereas I do see emacs/elisp related posts from time to time (with particularly strong mentions for org-mode or magit), and I don't have much memory of them.

Perhaps vim is so widely used now that no one bothers to vote up articles about it. I find the shift particularly strange because it comes with a shift of the site away from lots of articles about languages like lisp for which emacs is basically the only sane choice of editor.

Perhaps the real reason is just that I've noticed emacs more because I've used it more.

</comment><comment><USER75> Honestly the hardest part about emacs for me has always been documentation. Like how do I build a plugin. What function do I call to set a custom key binding? This stuff has always been so hard to find despite it being so important to the underlying experience. Now that I've used it for a while I know these things, but they didn't come easily.

<comment><USER55> These days you can just google to get answers quickly, just like for any other tool. Stackoverflow, etc. has tons of content for emacs too.

<comment><USER76> It's ridiculous that end users should rely on third parties for reliable documentation. For any other tool, if you wanted to know this kind of builtin functionality it'd be readily accessible in --help, the man page, or first- party online docs. Why should Emacs be an exception?

<comment><USER77> What tool do you go to the official docs for first and only Google second? I Google everything first. Am I missing out?

<comment><USER78> A trivial answer is "internal tools"...

A more interesting answer is bash - I will often check the man page before I Google.

</comment></comment></comment></comment></comment><comment><USER79> From: email@example.com

In general, the way for a problem to be fixed is for someone who knows how to fix it right simply to do so. Any solution that involves discussion should be avoided except as a last resort, because it is inefficient.

<comment><USER77> Is this a real email? Do you have a reference? Google didn't turn anything up.

<comment><USER79> Dale Worley posted it to a mailing list in '89, and I asked him where it came from:

        Date: Mon, 18 Sep 89 21:55:13 EDT
        From: email@example.com
        To: firstname.lastname@example.com
        Subject: An interesting bit of philosophy from RMS

           From: Don Hopkins <email@example.com>

             From: email@example.com

             In general, the way for a problem to be fixed is for someone
             who knows how to fix it right simply to do so.  Any solution
             that involves discussion should be avoided except as a last
             resort, because it is inefficient.

           Interesting all right! When/where and in what context did he say
           this?

        It was on one of the Emacs newsgroups, where lots of reasonably
        uninformed discussion had broken out on how to resolve the fact that
        VM and Gnus (I think) interfered with each other, because they both
        used the overlay-arrow mechanism.

        Dale

Searching Google Groups for the first sentence found the unexpurgated version:

[https://groups.google.com/forum/#!search/%22In$20general$2C$...](https://groups.google.com/forum/#!search/%22In$20general$2C$20the$20way$20for$20a$20problem$20to$20be$20fixed$20is$20for$20someone%22/gnu.emacs/p4sUVns_APg/945MYv3CBrMJ)

        Date: 9/11/89
        From: email@example.com
        Newsgroup: gnu.emacs
        Subject: No more on overlay-arrow-position

        I don't think most Emacs users want to participate in a discussion
        about how to solve a fairly obscure problem in how Emacs is implemented.
        This kind of discussion doesn't help me solve the problem.  I know you
        mean well, but you aren't experts.  Most of this discussion consists
        of proposals that are completely wrong, or won't work, followed by
        refutations and counterproposals.  When I decide to fix this for
        version 19, I won't read the discussion; I'll just fix it--it will
        take less time.

        In general, the way for a problem to be fixed is for someone who knows
        how to fix it right simply to do so.  Any solution that involves
        discussion should be avoided except as a last resort, because it is
        inefficient.

        Remember, the purpose of info-gnu-emacs (and its repeater newsgroup,
        gnu.emacs) is to carry the information that *every Emacs user will
        want to know*.  There's nothing wrong with non-experts discussing how
        Emacs bugs might be fixed, but please don't do it here.

RMS also doesn't like people posting baby announcements to mailing lists that are clearly intended for making dinner arrangements (and the baby in question is 27 years old now):

[http://www.art.net/studios/hackers/hopkins/Don/text/rms- vs-d...](http://www.art.net/studios/hackers/hopkins/Don/text/rms-vs- doctor.html)

I love Lile's response, who has the grace and composure of dang:

>Please send your "fucks" via personal mail and refrain from using Kabuki-west for such messages. -Lile Elam

<comment><USER77> Very interesting. Thanks!

</comment></comment></comment></comment><comment><USER80> I use Emacs and love it, but the problem as a newcomer is that basic questions never have basic answers. The answer is either in the form of a complex incantation, or requires one to come to grips with new abstractions.

</comment><comment><USER81> Emacs is eternal. It was here before most other editors and will outlive the majority.

<comment><USER82> > It was here before most other editors and will outlive the majority.

While your first statement is true, taking the second one for granted is dangerous and may lead to the exact opposite.

Every long-term FOSS project needs to continuously ensure it maintains a healthy level of contributors, or it _will_ die.

</comment></comment><comment><USER62> I think that the Emacs _concept_ is really good, but it clearly has a lot of problems that make it altogether unattractive to new potential users.

\- The keybindings are not the standard CUA ones. Even with Cua Mode, every page on the internet still suggests using the regular old Emacs keybindings. There's weird conflicts between some packages, especially if you use non- default keybinds like Evil. The defaults are not even ergonomic (Emacs pinkie is a thing...) or mnemonic, so there's really nothing but historical interest that makes them the way they are.

\- There's no namespacing between packages. They can run right over each other and cause weird bugs. This isn't theoretical; it's what happens when you have a bunch of packages installed. Sorting out performance issues caused by the interactions between packages is very challenging.

\- Lots of other defaults are super user-hostile. To get anything approaching the productivity of an editor like Sublime or VS Code, you have to spend hours installing packages, learning their unique keybindings, and sorting out conflicts.

\- The base is minimal in a way (it's missing a ton of what is needed to be considered useful today) and also very bloated (it has things like mail readers and web browsers and IRC clients included). The set of default utilities needs to better match what people actually use a text editor for.

At the same time, it does do plenty of things right:

\- From anywhere in the editor, you can run code---you don't need to make a new package to be able to execute a snippet of Elisp.

\- Unicode works OOTB, which is impressive for a project of that age.

\- Some of the "killer apps" like Magit and Org-mode are really good and have spawned their own ecosystems.

\- Emacs is oftentimes the first editor to get support for super-obscure programming languages through a package.

A lot of what makes Emacs so cool and so difficult comes from the fact that it doesn't have an "extension API"\---packages just run the same kind of Elisp that the editor itself is (mostly) written in.

Edit: I should also add that Elisp is an absolutely _terrible_ programming language when compared to more modern alternatives.

<comment><USER55> > To get anything approaching the productivity of an editor like Sublime or VS > Code, you have to spend hours installing packages, learning their unique > keybindings, and sorting out conflicts.

Isn't it the same with VIM or other free editors?

<comment><USER82> To be fair these days you come far by just installing 'lsp-mode'.

</comment></comment></comment><comment><USER83> I like emacs' aesthetics. It looks like something developers would use in a movie, especially with the colors set dark and the scrollbar on the left where all scrollbars ought to be.

I agree that aesthetics have importance, but they should complement what emacs is and how its used, not make it pretend to be something else. Emacs is a powerful tool, that isn't going to change-- so it should look like one.

There are already many editors with a "sleek look"! So users that want that are already using one. They won't switch to emacs if emacs adopts a sleek look, especially because emacs' internals won't match the drapery.

Emacs epitomizes the Hole Hawg in Stephenson's excellent "In The Beginning Was The Command Line" ([https://steve- parker.org/articles/others/stephenson/holehawg...](https://steve- parker.org/articles/others/stephenson/holehawg.shtml)). It should lean into that. The users it loses from being overly industrial are ones mostly wouldn't stay, but the ones it gathers will stay because there are few alternatives. There is always a role in the world for serious tools.

</comment><comment><USER84> > Terminal-based Vim is not like a modern application, yet is more popular > than Emacs.

As someone who has started out with vim, spent a couple years using emacs (with evil-mode) and ended up with vim (more accurately neovim) again, here's my take on why this is.

First of all, I ssh into a lot of systems that have vi(m) installed, but not emacs. So, if I am using vi bindings for my main editor, I don't have to switch to using completely different editor bindings on remote systems. For other's that are in a similar situation, that's also an incentive to learn vi over emacs.

Secondly, while vi(m)'s modal editing is difficult to master , once mastered, it is, IMO, amazing. Emacs otoh just has unfamiliar, and sometimes unergonomic key bindings. While many editors do have "vim modes", I have ultimately been unhapy with most of the one's I've tried (evil mode for emacs is ironically one of the best).

Finally, there is the configuration. Both emacs and vim are extremely customizable. While VimL is certainly not the greatest language, it is at least fairly familiar to programmers with experience with ALGOL-family languages. It's also somewhat straightforward to write plugins for vim in other languages, such as python and lua. Emacs otoh, uses Emacs Lisp. And while I admire lisp, it is certainly very unfamiliar to many potential emacs users, and can often be much more verbose, especially for setting custom key bindings.

With all that said, there are things I miss about emacs. Probably the biggest is that several modes let me customize how auto-indentation worked. In vim, the ability to customize that easily is not very common, and when it does exist is not well documented.

</comment><comment><USER85> How on earth was RMS unfamiliar with the existence of Org Mode, and how on earth was RMS unfamiliar with the concept of outliners, and why on earth, when he finally figured out what Org Mode did, was his immediate response to be super dismissive because it wasn't something that he's interested in using personally?

He sounds like some random person spewing random subjective opinions about things, rather than the original author of GNU Emacs making an honest effort to provide leadership and guidance that means something (anything) to anyone other than himself. He sounds helpless and oblivious to everything and everyone except his own personal proclivities, which is the opposite of leadership and the opposite of an experienced person providing valuable guidance to the community. Like he's not even making a token effort to do those things, and to say he's metaphorically lifting a finger here to provide leadership and guidance would be very generous.

This is akin to Linus rejecting a driver because he doesn't own the hardware, or because he doesn't like the colors of logo of the company that makes it. It really doesn't get more incurious and intellectually/emotionally immature than that.

This is in 2020, after a couple decades of Emacs being one of the only actual software projects he involves himself in anymore. To be clear, I've had a really low opinion of RMS for going on 20 years now (after a few years in college where I thought he was cool because I didn't know any better and people seemed to revere him because they thought everyone else revered him). But reading these mailing list exchanges are still kind of shocking to me. It's really hard to believe that anyone on the GNU mailing lists pay any attention to him at all, or values his opinion on anything. For those that do, surely that's nothing more than a cult of personality, it just seems as plain as day to me. This is exactly the sort of thing that drives people away from GNU and the FSF, and it sucks because they could be so much more impactful and meaningful and helpful and positive and constructive otherwise.

Sometimes I think if more people had simply stopped making excuses for RMS like 20 years ago, we might currently be living in some sort of GNU utopia dreamworld where everyone everywhere uses Emacs for everything, and GCC is the preeminent compiler suite, etc. etc. etc. It's quite a high cost for people to pay, when the only thing they get in return for keeping this guy around is helping a damaged narcissist continue to feel good about himself and continue alienating everyone else, just like he's been doing for decades. He absolutely got GNU and the FSF off the ground and helped create a large community that has produced tons of great software, but in the past 25 years it seems like all of his efforts have been counterproductive to his own goals.

<comment><USER55> > How on earth was RMS unfamiliar with the existence of Org Mode, and how on > earth was RMS unfamiliar with the concept of outliners, and why on earth, > when he finally figured out what Org Mode did, was his immediate response to > be super dismissive because it wasn't something that he's interested in > using personally?

He seems out of touch even with modern emacs packages. He doesn't use any of them, doesn't even know what they do, I guess he uses the same config since the 90s, doesn't try new packages, he's more interested in preaching the GNU message.

<comment><USER82> > He seems out of touch even with modern emacs packages. He doesn't use any of > them

And he believes the right thing for the core Emacs-developers to do is to spend their time trying get everyone in MELPA (a modern package repo, with a modern GUI, based on modern tools and workflows) to instead move their packages to ELPA, with all the change in tools, modernism's and workflows that entails.

He seriously believes this is important because MELPA isn't GNU, and that's all he cares about. It's not enough to be open-source and free. You must be GNU, or it doesn't matter.

He may add things of value still, but I refuse to believe it's not overshadowed by all the backwardisms he constantly tries to impose on the core developers actually doing the dirty work.

</comment></comment></comment><comment><USER86> It really depends on your needs. For modern development of projects with bloated file structures, having a hand-holding GUI like VSC that tames the file structure of the project really is nice.

If you're just occassionally dropping into headless filesystems to do some text editing, you're not going to invest in learning a new paradigm and you will likely use whatever default editor is presented to you. That is typically vim. For those who mindfully choose to set out and learn a new paradigm because they've decided to invest in a long-term time-saving skill, I doubt the vim/emacs divide is quite as stark as the numbers mentioned in the article.

</comment><comment><USER87> The most unfixable UI problem for Emacs is that its rendering model works upon "character cells and cursor positions, not pixels."[1] No amount of effort would steer Emacs's UI away from an ortholinear matrix of characters. Whenever you install an LSP plugin on Emacs, you'll realize how badly it hurts readability and your eyes. [1][https://m.facebook.com/notes/daniel- colascione/buttery-smoot...](https://m.facebook.com/notes/daniel- colascione/buttery-smooth-emacs/10155313440066102/)

</comment><comment><USER88> When I started programming on ruby my laptop couldn't handle IntelliSense and tests which required too much cpu and ram. So I've switched to vim on server through ssh. Later I've switched to emacs as it seemed to me more powerful than him back then.

After I got MacBook I've switched to TextMate utilizing powerful macOS keyboard shortcuts for text navigation. MacBook was pretty fast to handle ruby-related tasks.

Later I found myself in IntelliJ idea working on my Scala projects with emacs keybindings. I intuitively used emacs keybindings everywhere - from terminal to text fields in browser (without changing defaults!). Pretty comfortable until...

I started programming in Rust. It's compiler and lsp servers use very much cpu, ram, compilation is really slow heating laptop like a frying pan. Here comes VSCode with vscode-remote which allows to write code on desktop gui while compiling, executing IntelliSense commands (lsp server to be exact), etc on a powerful cloud server. As I understand it executes everything remotely except GUI rendering and interaction. On network interruptions it restores connection seamlessly, I barely noticed. It was a salvation. VSCode has a bunch of predefined hotkeys which can be customized to fit my emacs-like navigation habits but there are always conflicts with some already existing bindings, also extension tend to add their own defaults. Too messy. Vim/emacs emulators are incomplete and buggy. This led me to weird trackpad&keybindings experience for navigating, building, debugging... Remembering how productive I was in vim/emacs I couldn't handle this despite perfect state of the art vscode-remote.

So I decided to give vim/emacs a try, discover how ecosystem changed during 10+ years. After some investigation I've landed on neovim and tried to work on a rented server as I used to in my first programming years. Experience was far away from VSCode-remote. Due to network lags and ssh overhead I can't be productive with all the benefits neovim offers. So I ended up buying a powerful home server, connecting to it from my MacBook and work in neovim over ssh. It's ok but I really miss the "true" remote mode which offers local almost zero-latency editing with remote everything else. Renting powerful servers which has access to the whole dev infrastructure. Paying for them hourly. There are so many discussions about/plugins implementing VSCode and its extensions features in (neo)vim/emacs but in my opinion the really missing piece which don't turn (neo)vim/emacs to VSCode but instead makes them as powerful as VSCode in cloud-powered code development. Am I the only one who miss this feature?

<comment><USER89> I think what you're looking for is TRAMP [0,1]. After resisting it and continuing to ssh into remote hosts in a shell, I finally started to switch my workflows over, and the improvement is substantial. Async remote compiling might work out of the box in some cases, or it might require some additional configuration.

0\. [https://www.gnu.org/software/tramp/](https://www.gnu.org/software/tramp/) 1\. [https://www.emacswiki.org/emacs/TrampMode](https://www.emacswiki.org/emacs/TrampMode)

</comment></comment><comment><USER90> Making it more popular is going to make it worse. Already in this thread people want javascript shoved into it. Emacs can be improved in many ways, but if it strives to be popular the opposite will happen.

</comment><comment><USER91> There is a human aspect to software, and when you forget that, and try to force people to adapt to software instead of adapting software to people, you come up with software that naturally is difficult and unpleasant for people to use.

Emacs is built on a philosophy of human nature that deemphasizes the subjective personal experience in favor of (a limited group of people's theory of) the objective ideal experience.

In a short amount of time, VSCode and it's ecosystem has almost equally matched what Emacs and its ecosystem took 30+ years to create.

<comment><USER92> > In a short amount of time, VSCode and it's ecosystem has almost equally > matched what Emacs and its ecosystem took 30+ years to create.

I'm not $o $ure that'$ actually a$ impre$$ive a$ it $ound$ ;)

<comment><USER91> I think you're making the point that a majority of VS Code was funded by Microsoft, and therefore it can't be compared to Emacs which was either mostly or entirely coded by volunteers?

The vast majority of Emacs's usefulness is its ecosystem. Several Emacs clones have been made in a very small amount of time, but none have caught on because they lack the ecosystem and community. So it's only really fair to compare VS Code's ecosystem with Emacs's ecosystem. And VS Code's ecosystem was created by unpaid volunteers too.

</comment></comment></comment><comment><USER93> I've had Emacs open in my screen while I'm working for twenty mutter mutter years, and my keybindings have diverged enough where I can't use stock Emacs without stopping and carefully thinking about what I'm doing.

But that's sunk cost. I discourage young programmers from diving into it, for a couple of reasons. First, early in their career there are places where they will get a lot more leverage. Spend some time learning your text editor, sure, but at the five to ten hour mark that rabbit hole starts yielding swiftly diminishing returns. And second, everyone talks about shaping it to your workflow, but, in the end, Emacs is a terrible environment for writing UIs. Not everything is best interacted with as text in a terminal. In fact, most data is not. Compare org-mode with the best of breed todo apps like OmniFocus and Tasks. I use org-mode for my technical diary, and I use OmniFocus for my tasks. OmniFocus is simply better. GUIs with a mouse are a more efficient way to navigate most tasks on a computer that aren't programming.

Stallman mentioned preparing text for publishing. I'm probably unusual in that I have both typeset professionally (back in Quark XPress days) and gone really deep in to LaTeX (in my physics days). I've written and typeset two books. The technical text I did in LaTeX. Actually, I wrote the text in a mix of Scrivener and LyX, and then used Emacs for the final document. For what lies nicely in LaTeX, that's great. The other one I did in Adobe InDesign, and doing it in LaTeX in a text editor instead sounds like masochism. If you're willing to accept what LaTeX gives you, it's fabulous. If not, typesetting with Emacs and LaTeX is a simply inferior experience to using a proper typesetting program.

</comment><comment><USER94> I'be been using Emacs for 17 years mostly for programming-related tasks. My opinions are:

\- Emacs is an editor for people who think that learning some Lisp sounds fun if they don't know some already.

\- Emacs should not bother trying to appeal to a more general audience; it's not an editor for most people when new to programming, and it's an editor for a very small minority of non-programmers.

\- Emacs should focus on its strengths: it is the most powerful and extensible editor ever created. As long as it looks after that identity, it will always be highly respected.

\- The infinite customizability via emacs lisp and the ecosystem of libraries is the only thing that can make Emacs more attractive than other editors.

\- Emacs should be sleek, minimal, fast, and visually beautiful, by default.

\- The customize interface is ugly and not a priority; it should be expected that Emacs users will configure things in Emacs Lisp.

\- The clunky default icons and splash screen should be got rid of: present a blank screen with minimal tooling if a beautiful first impression cannot be created.

\- Many of the elisp packages that ship with Emacs should be removed from the core, with users installing them as packages (Org-mode, Gnus, etc), leaving a more easily maintainable core.

<comment><USER95> I agree that a leaner core seems intuitively right. However, the discussion on emacs-devel has been in the other direction as of late [https://lists.gnu.org/archive/html/emacs- devel/2020-04/msg01...](https://lists.gnu.org/archive/html/emacs- devel/2020-04/msg01421.html).

<comment><USER94> Thanks I skimmed that thread and the one this HN thread is about. There are so many depressing things. In particular this arrogant and utterly ignorant condemnation of Pull Request-based workflows infuriates me:

> A lot of people have not been contaminated by the entitlement that comes > with the "I'm sending a PR, please check it in" generated by the Github > culture.

I don't think the person who wrote that has even looked at the pull request review that goes on in high quality emacs packages on GitHub, let alone participated in it. This sort of thing really makes it clear that some of the people on emacs-devel are hopelessly out of alignment with the majority of the people would would willingly contribute to the emacs and emacs lisp package ecosystem.

There are many good reasons not to included packages in core Emacs. A big one is that package authors are working in their own free time and don't want or need to have to prepare an especially bug-free release to coincide with Emacs release cycles. Also they don't want to support users using the old version that is in Emacs.

</comment></comment></comment><comment><USER96> The Emacs community has held itself back by continuing the line of thought of resisting anything that fundamentally changes what they already have spent years learning and know. It's their power tool, and using tools is important for humans to do their craft. So I understand why they don't want anything to change.

Meanwhile new generations of people have different tools and aren't held onto these past ones because they didn't start with it (and they weren't coding in the 80s). The world of computing generally has moved on with new ideas, new experiences, and new form factors. So their new tooling has won them over, and outcompeted a dying generation.

This is a good thing! It's called progress. Unless Emacs is willing to have fresh blood decide a new direction for it, it will be relegated to history. If Apple held onto its Apple II vision, we wouldn't have the iPhone today. Either you are willing to fundamentally change with the times, or you aren't. Emacs has shown they aren't, and they've had over three decades to do so. Fortunately others will in their place!

<comment><USER97> I can imagine a few ways emacs could be improved, but "a new direction for it," I can't.

<comment><USER96> And that's why it'll slowly go extinct.

<comment><USER98> Newness contradicts creativity, because the creative process needs to result in objects that last. In fact, because new designs create a future need for more new designs, it cannot last by definition!

Think of shops that sell novelty items. Newness at an object level looks like novelty items. What is the quality of novelty items? How long do novelty items last?

<comment><USER96> I don't understand your point. We're not talking about physical things, we're talking about software. Software is always changing, morphing, adopting, and growing user bases. It's what's amazing about it compared to hardware. My 2012 MBP runs the latest OS from approximately 8 years later, and with it a whole new slew of features and additions that both Apple and the rest of the world have brought it. Why be stuck in the past?

<comment><USER97> > _Why be stuck in the past?_

I surely would want to go back to the pre-corona days.

</comment></comment></comment></comment></comment></comment><comment><USER99> How much can Emacs change while still being Emacs? Is it worthwhile to start building a new editor on the core Emacs "idea"? Because I think minor changes will not move the needle. Someone compared it with the birth of Firefox, scrapping Netscape Mozilla Communicator or whatever it was called. I think that is what it would take but even that would be uncertain.

<comment><USER100> I have used emacs for decades so I do not see the need for a big restart, but your question does remind me of something RMS said years ago. I cannot find the exact quote, but the essence of it was that any editor that offered the programmability of emacs was worthy of the name regardless of its keybindings, etc. In that sense I do not believe there would be any problem with emacs following the model of Fortran; it can look and behave quite different, but at its core it has to be open and accessible for the user to extend and adapt.

</comment></comment><comment><USER101> It's still popular with me :)

In fact instead of being in either the vi or emacs camp, I use both. I also use Eclipse.

Each of them for the task at hand.

<comment><USER79> Eclipse was designed and named to piss Sun off, and it worked.

<comment><USER102> Fun fact about the Eclipse name, thanks.

</comment></comment></comment><comment><USER103> > You are basically making a commitment to being or becoming a power user. I > certainly would not have put up with it if I didn't think it was going to > save me a lot of time as a software developer (and it does, everyday). I > doubt anyone invests the mental effort to deal with learning emacs nowadays > unless this is their goal.

> Terminal-based Vim is not like a modern application, yet is more popular > than Emacs.

I think what happens here is that when someone decides they want to invest the time to learn an advanced editor, most of that subset of people end up choosing vi. Emacs is not approachable enough to appeal to people who _don 't_ fall in that group, and vi has more obvious productivity wins for someone who _does_ enter that group, since its focus is on velocity-of-editing rather than extensibility, the latter of which is not even that unique any more (see VSCode/Atom).

</comment><comment><USER104> I've spend 4 years mastering vim and I can definitely say I could have spent that time better elsewhere. I'm pretty sure Emacs would be the same waste of my time. These editors have a very steep learning curves and require a lot of effort to master.

Don't buy into the meme, at the end of the day they are just text editors.

<comment><USER105> It took me maybe a few hours to learn vim and I could be decently productive in it. After that I just learnt through exploration.

For me it was definitely worthwhile. Vim is almost everywhere so I can easily edit text wherever I go.

</comment></comment><comment><USER106> Not to be divisive but I see a parallel here with what happened in the gaming industry. As it became more popular and socially acceptable, the quality of games went down, from the perspective of people who played games when they were unpopular. Eg. baldurs gate vs fortnite. Development is now fueled by an insatiable industry demand and fairly high salaries, and a lot of offshoring to desperate countries where it's a way out. The taste of people who only write software in the context of cultural cache and a salary is always going to be different from that of people attracted to something for its own sake.

This conversation even reflects that- Too comment how many days before I can be productive for X company in JavaScript from scratch? That's not a question I'm interested in but it's been accepted as the most interesting question here.

</comment><comment><USER107> How do you make scrolling to work not line-by-line but pixel-by-pixel in... MacOS and Ubuntu? There's some arcane installs that are each incrementally better than the next one but none match the native scrolling experience you'd usually see in a modern/graphical text editor

</comment><comment><USER108> What makes Emacs attractive to me is that it's a programming environment which you can modify on the fly. At least, that's what I have read, I've never actually done it myself.

Visual Studio Code, the editor that I use daily, is based on Javascript (Typescript) but I have yet to see a page by Microsoft explaining to me that I can quickly whip up a script and execute it in my editor. From what I understand you need to create an extension and I think that takes a bit of setup.

A spiritual successor to Emacs could be an extensible editor based on a language which you can interpret on the fly, modifying your environment as you go along. That's what would make Emacs more attractive to me, along with modern keybindings like arrow keys...

<comment><USER17> FWIW, Emacs does support navigation via arrow keys by default, unless I am misunderstanding what you mean.

<comment><USER108> Ten minutes after I posted my message I just realized that the concept of a Macro has been around since the dawn of computing and is in large part responsible for the meteoric rise of Microsoft (along with a lot of viruses)

What I mean is I'm looking for a editor with macro capabilities that can be programmed in, say, Javascript, Python or Lua.

<comment><USER109> Neovim is an editor with macro capabilities, which can be programmed in LuaJIT.

It's my terminal editor of choice, and yes, arrow keys work. But why would you want to use them?

<comment><USER108> I've been using vim for 15 years so I know neovim.

But ... can you make changes in neovim while it's running?

Let me take it a step further. Imagine a text editor in which you can, while it's running, literally go into its source code and make changes and that those changes immediately take effect. If I'm not mistaken you can do that in emacs. That's what I find intriguing about it, not the text editor.

<comment><USER109> I believe so, yes.

Neovim is less programmable than Emacs insofar as more of it is written in C, it's substantially less documented, and Emacs has a substantial head start.

But yeah, still fundamentally a programmable text editor. If you wanted to set up a file watcher over source code that automatically reloads it when files change, there's nothing stopping you.

It's true that nothing other than Emacs is _quite_ like Emacs. Neovim is evolving in the right direction though.

</comment></comment></comment></comment></comment></comment><comment><USER110> Emacs 100% lacks a reasonable sidebar strategy. I use Visual Studio Code's sidebar for 3 things, navigation via search, navigation via changed files, navigation via directory tree. It is very fast to use all of those, even though they are mouse oriented.

The only comparably fast and useful ripgrep that works out of the box in Emacs is swiper, but it uses a temporary buffer. Deadgreap is great but you have to harangue it behave in a similar way to the sidebar in vs code and even then it's just not the same.

The other thing is emacs regexps suck and PCRE is the standard of every well used regexp implementation in the world at this point and emacs ought to find a way to transition to it.

<comment><USER111> You can use keyboard for all of those things in VS Code, just by the way :)

(On the team)

<comment><USER110> Awesome. Y'all do great work. I have a couple of questions if you are checking this thread:

1\. Do y'all do security analysis on extensions? Static analysis etc? Specifically, I am talking about detecting potential source exfiltration type stuff.

2\. Any chance you'll develop the ability to customize the editor via some personal scripts vs a plugin? I'd like to implement a command to do a specific thing (toggle between test and implementation in a rails project) but I don't want to go through the process of creating a plugin... I just want to map a shortcut to a TypeScript function. I know there is a couple of extensions that try to enable this but it would be nice to have an official path to doing these kinds of personal customizations.

<comment><USER111> 1) see info here: [https://code.visualstudio.com/docs/editor/extension- gallery#...](https://code.visualstudio.com/docs/editor/extension-gallery#_can- i-trust-extensions-from-the-marketplace) I'm not going to say more here, but if you post an issue someone will get back to you. :)

2\. I'd recommend just finding an extension that does this. It wouldn't be hard for an extension to implement, and supporting multiple extensibility classes in core when we don't need to probably won't happen. What exactly are you looking for in an "official path"?

<comment><USER110> In Emacs land, ~/.emacs is executed as an arbitrary code. I would like to be able to have a ~/.vscode.ts that contain a function and I would like to map that function to command+t. It doesn't seem like a stretch to offer that feature. Right now I have to use something like this:

[https://marketplace.visualstudio.com/items?itemName=ego- digi...](https://marketplace.visualstudio.com/items?itemName=ego- digital.vscode-powertools)

<comment><USER111> I encourage you to look into writing extensions, an extension which simply registers a command that executes some script at a fixed location would be a good starting point for learning.

</comment></comment></comment></comment></comment></comment><comment><USER112> I still consider myself an emacs user even though I haven't used it for over a decade (or 2?).

For me emacs is from a time where text was king - the productivity to use Emacs for my entire work process - latex docs, coding and debug in multiple languages, reading email, accessing remote systems (gdbserver, scp, ftp, even gopher and the web) from within emacs without using the mouse was astounding.

But as things become more graphical - rich text email was the first, then the web, UML, word/excel etc it became less useful.

Emacs feels like a long lost lover - sweet memories from a distant past, but you can't go back.

</comment><comment><USER113> First of all I really like the value of Emacs as a modern lisp machine. And it is the best environment to write in any lisp language.

But for anything else it is not good enough. Emacs Lisp is better then vimscript but only if you are extending it. For just configuration I prefer vimscript because it is so terse.

But IMO just better then vimscript is setting the bar too low. Imagine if it had something like Neovim's msgpack and you could extend it in any language you like. I am still hopeful something like that will happen.

</comment><comment><USER114> It would be cool to have package statistics to know which packages are more popular/used. The community is too fragmented at this moment, and there are too many competing packages. While it's good to have diversity, having package statistics will make it easier to choose the best packages for end-users and package developers will focus on improving the most used packages. It will also improve compatibility between packages.

Or is this already implemented? VS Code does it and it's a good feature.

<comment><USER49> [https://melpa.org/#/?sort=downloads&asc=false](https://melpa.org/#/?sort=downloads&asc=false)

</comment></comment><comment><USER115> I love Emacs. I don't use it beyond dabbling. The contradiction? I'm not a full-time computer professional. Keeping Emacs stable and running just takes too much bandwidth. It's a tool for dedicated professionals who get a massive return on their investment spent optimizing and maintaining their Emacs setup. Sadly as much as I love the idea of Emacs, I don't personally get enough productivity return to justify the investment. It's not a flaw with Emacs.

<comment><USER116> > I'm not a full-time computer professional.

Emacs is used by non-computer professionals as well. If your profession relies on the manipulation of text, emacs is the tool to use.

>their investment spent optimizing and maintaining their Emacs setup.

It's really not that bad. Say you're a fiction writer: you only need to figure out your preferred workflow once, but then you can use it for decades with only minimal changes.

Of course, once you get the hang of it, you might think it convenient to be able to write short mails directly, or do a bit of your own typesetting all from the comfort of your, by now, favourite editor, but .emacs files usually see very little churn. What's in a .emacs has usually just accumulated slowly over the years as one's usage of the program increases.

</comment></comment><comment><USER117> IDEs come and go, Emacs stays.

Turbo Pascal (wayyy back) was quite impressive (then), Visual Age for Java much more so some fifteen years later. IntelliJ is alright (prefer it over Eclipse, which somehow managed to lose the smart features of its predecessor). Haven't tried VS Code yet, but from the videos I've seen, it seems quite handy.

I stick with Emacs for two reasons: familiarity and SLIME (the next best thing to a LISP Machine ;-}

</comment><comment><USER118> It seems to me that productivity is the assumed goal. But that is not the whole story. I also enjoy using Emacs. I appreciate and support its commitment to free software. I like that _everything_ is customisable.

Also, I wonder if it would be possible to do a study on productivity between IDEs. It seems to me much of the data would be measurable. One idea would be to allow github users to state their IDE.

</comment><comment><USER119> I still use enacts for all my coding (with cua mode on), mostly because I have yet to find another tool that does context sensitive indentation quite right. And I suppose I'm just used to it. But I don't actually use most of the power features. I mean code is just text; all i really need is normal editing, and the occasional search and replace. I also use org mode for all my notes.

</comment><comment><USER120> Maybe not the appropriate forum but does anyone have a sane setup for the insane javascript setup of modern times?

I love emacs and am willing to put the time into tooling and configuration. But despite several hopeful attempts, I've been unable to manage anything comparable to vscode for this environment.

That is, support for all versions of ecmascript, but also jsx, typescript, et al.

<comment><USER121> Sorry I don't use emacs, but Vim/Neovim is pretty easy to setup with coc and all it's subextensions for stuff like eslint, tailwind, vue and whatever. It's essentially just the VSCode language server running in Vim and it's awesome.

<comment><USER120> I appreciate the input and will look into the VSCode language server.

</comment></comment></comment><comment><USER122> One thing I've noticed is that I'm using not only Emacs but other editors, I really like Org-mode for notes and cider-mode for Clojure but I find myself switching to other editors including vim and VS Code when doing other tasks.

Perhaps something like Spacemacs but built around CUA-mode with a nice default theme and menus will win people to the platform.

</comment><comment><USER123> I've been a vi user for about 30 years. Once, a few years back, I decided to force myself to use emacs for a year to see if I could understand what people saw in it. Once I realized, 10 months in, that I was counting the days before I would "let" myself use vi again, I finally threw in the towel and bailed on emacs.

</comment><comment><USER124> If they could make some kind of a visual layer that makes it look like Word and Photoshop (not in the same time, I'm being realistic here), their name would be remembered in eternity.

Of course, emulating the shortcuts & functionality of Word and Photoshop shouldn't be considered a problem, we are talking Emacs here after all...

<comment><USER125> A closer example might be autocad (at least older versions). You could do everything with a mouse, but a true expert could type the plans for a building faster than you can imagine.

<comment><USER124> Yes, that's why it's fishy that GIMP doesn't emulate the Photoshop shortcuts/menu structure.

But any arguments regarding word editing in latex markup I won't accept.

</comment></comment></comment><comment><USER126> I used to use emacs daily, but nowadays sticking to "mg" and "vscode"...

<comment><USER55> Org mode is really good for note taking, so emacs has uses even if one does not use it for programming.

<comment><USER127> I gave it an honest try for 6 months and even as good as Org-mode is (I used it to track project tasks, notes, timelogs, even had a go at custom templates), the 80s design choices and trying to find information that didn't expect a full working knowledge pushed me away from Emacs, might have been made worse trying to do this on "the devil's OS".

I'd have loved to have been able to give magit a go.

I do still have Orgzly on my phone though.

</comment></comment></comment><comment> pcj-github Used emacs for years, switched to VSC as it's just more compatible with the present time in terms of plugins, languages, and even simply working with other people. Emacs is a thing of the past. I do really miss the kill-ring though.

</comment><comment><USER128> I like Vim better because it's easier for me to press one key to do an action or write :command. I can also use Vim on the mobile (Termux and other terminals). Having to press CTRL+A CTRL+whatever doesn't make sense IMO.

</comment><comment><USER129> I attempted to learn Emacs first, then settled into VSCode+Vim.

I even tried recently, but failed again.

So, please share some good resource for learning emacs. That is the biggest issue with trying emacs to see if it suits.

As it cannot be tried, its not considered.

Please suggest.

</comment><comment><USER130> Just got a new Mac computer with Catalina pre-installed, and was surprised to see

        zsh: command not found: emacs

Of course, I can (and did) install it myself, but it used to be included by default.

<comment><USER131> I imagine that Apple is trying to remove GPL-licensed software from macOS. Similar to the replacement of Bash (GPL) in favour of Zsh (MIT).

</comment></comment><comment><USER132> The which-key feature (whos you key bindings by pressing the first key) of doom and spacemacs is great for discoverability but would be infinitely better if they also had a key binding instant search.

</comment><comment><USER133> I'm not programmer, but I'm interested in emacs because someone say it can be devonthink alternative, tried spacemacs, for a weeks, still don't understand how its behave

</comment><comment><USER134> If it was a tool to be mastered, there should be a way to learn it. Unfortunately, due to the many, many ways to customize it, I struggle to see a clear path to emacs mastery.

</comment><comment><USER135> First we need to make Common Lisp popular. Since it's nigh impossible to write Common Lisp in any other editor, Emacs will certainly experience a surge of popularity.

</comment><comment><USER136> Awesome! I haven't seen a good "Emacs vs. x" thread in _years_!! People are coming out swinging as well! Woohoo! Where's the popcorn??

</comment><comment><USER137> I will repeat what others said but here we go. On my work pc, on windows, VSCodium works much better when it comes to graphics.

</comment><comment><USER138> Firefox mode for Emacs would make me never leave emacs for anything else.

Multi threaded Emacs would be very nice as well.

</comment><comment><USER139> one reason i did not use EMACS is it is a bit slow in my Mac air, maybe i should buy a better machine.

</comment><comment><USER140> Emacs works poorly on Windows, that is the only reason I don't use it.

</comment><comment><USER141> I tried to learn emacs but after the week of struggling through arcane keybindings and the bizzare quirks I just noped. Emacs is cool but it did not age well in a way that any software with three decade+ history would.

</comment><comment><USER142> They need to restore the foot pedal options.

</comment><comment><USER143> Better defaults on the vanilla installation would be a nice.

Apart from that: How dare you criticize a god?

</comment><comment><USER144> Emacs is awesome. The default setup is near useless. Elisp is really not exciting.

</comment><comment><USER16> Folks, I want to disabuse you of the notion that in order for Emacs to be any good in 2020, it needs to be "modern". It needs a modern UI. Emacs Lisp should be replaced with a modern language like JavaScript. Its display backend should be replaced with something modern like embedding a browser engine and rendering to HTML5. (I have literally seen this suggested on /r/emacs). At any rate it should be accessible via a browser in the cloud, because in the future everybody will develop in the cloud. If somehow the maintainers do all of these, then it would only serve to effectively transform Emacs into Visual Studio Code, and it would make a shitty clone of Visual Studio Code at that. So modern. There are parallels with the efforts, started in the late 90s, to make Linux into an inferior clone of Microsoft Windows to increase its popularity.

The problem is, much of what today's twentysomething webdevs consider modern is mere fad. It is not objectively better (and is sometimes objectively worse) in terms of user affordance than what we had in the 90s. The current trends in UI design obscure distinctions which were bloody obvious in the days of bevelled gray buttons. Browser engines run like pigs, especially when compared with simple bit-mapped windows, and developing in the cloud hits a brick wall when your network connection goes down.

I want you to try something. Try to imagine Emacs not as an ancient editor in need of modernization, but as a programmers' tool _from the future_. It may be a grim future indeed, one in which programmers learned some harsh lessons -- that not all programming is webdev, and the dominance of webdev in the field today is likely to be short-lived; that CPU and RAM are cheap, but not free; that networks go down; that software the user can't examine and completely control is software that is potentially hostile to the user; that the job of a program's UI is to enable work and not to dazzle the user; and that programmers have a higher duty to expand their users' minds, making them capable of more than when they started, and not to simperingly cater to 1984's notions of what an absolute beginner should experience. (The implications of the fact that Stallman learned many of these in the 70s and 80s is left as an exercise.)

But a program from far enough in the future is just as incomprehensible to today's users (especially today's generation-Z webdevs) as a program from the distant past, the difference being that the future program is likely to be much, much more advanced -- and today's users can learn a lot by understanding it on its own terms as they try to unlock its secret power. So it is with Emacs -- an omni-tool designed to be shaped and sculpted by the user into just the thing for the task at hand _as the user works with it_. No kidding --hacking something together in Emacs Lisp is so easy, for many data munging tasks it compares favorably to _regular_ Lisp. Such hacks may not be beautiful or elegant or even production-ready, but if they let you get a job done quickly, they're valid. When you combine Lisp's eldritch power with the ubiquitous buffer abstraction and all that enables, you have a juggernaut for information workflow optimization -- and by comparison, Visual Studio Code is explicitly designed _not_ to be extensible in such an ad hoc fashion.

Try this in your editor: Emacs has a command M-. If you are working on some Emacs Lisp and you type M-. on a symbol with a function binding, Emacs will jump to the function definition, opening the file it's compiled in if necessary. If you keep drilling down like this, eventually you will hit bedrock: the primitive functions of Emacs implemented in C. If you compiled your Emacs from source, and you say M-. on one of these, Emacs will _remember where its own source lives_ and take you straight to the C file and line where the primitive is defined. This, my friends, is the quintessence of open source.

Plus, Emacs can talk to text terminals and bitmapped displays, and almost everything works the same either way. When I finally get my VT330 working, I'm going to hook it up to my sweet-ass Ryzen box, fire up Emacs, and take advantage of all its modern -- nay, _futuristic_ \-- power from my 1980s terminal. Why? _Because I can._ More practically, this means Emacs can communicate with its user over very low bandwidth channels -- making it ideal for working with remotely, cloud or otherwise.

And all this in an editor, several instances of which can be supported by a cheapass SBC like the Raspberry Pi. It's a bloody miracle of design, even as its hackishness is made manifest.

Emacs doesn't _need_ to be changed to suit the whim and caprice of today's developers. Emacs is eternal, an emanation of the Tao; if it were to somehow disappear, somehow some way we would re-make it from scratch. It's not without faults, it can be improved, but the ideas behind it are transcendent and unmoving, and should not be compromised in favor of webdev fads. Let it shine forth like a beacon unto the void, and let its luminousness enlighten all those who are drawn to it.

</comment><comment> Iwan-Zotow I heard it is called VS Code nowadays

</comment><comment><USER145> vi > emacs

If you disagree you're either just a troll or lying to yourself

<comment><USER146> Emacs has vi emulation. Does vi have Emacs emulation?

</comment></comment><comment><USER147> The only way emacs get popular is if it changes its licensing.

Everything else is just window dressing.

</comment><comment><USER148> One thing is to make the keyboard shortcuts better.

Get rid of the ancient and archaic method of Ctrl-C to start a command chord. Reserve that for basic commands like copy and paste.

Instead, use the slash, Ctrl-/ to start a command chord. This way, you can use all the nifty shortcuts you want, and still not interfere with common commands.

Another feature is to use Ctrl-Spacebar to allow a search of command aliases.

Like, highlight your words, then hit Ctrl-Spacebar, then type "upper", and it'll do a dynamic search for all matches, and one of those matches is to make the selection uppercase.

This can be useful for all types of commands and personalized macros.

But then, the other problem for Emacs, is that Visual Studio Code is pretty damn good. And it also works on Linux. Its memory footprint is really high, taking about 85 MBs of RAM, but Emacs takes like 30 MBs, so it's less than 3x more, for much better features. But, it's not like I'm using a 20 year old laptop anymore.

<comment><USER109> > _Instead, use the slash, Ctrl- / to start a command chord_

This has an obscure problem, of which you were no doubt unaware.

In the terminal, Ctrl-/ sends backspace. Emacs isn't commonly used in the terminal anymore, but it can't become useless in the terminal, and this change would make it useless.

Unfortunately this is a non-starter.

<comment><USER148> Then use the dot: Ctrl-.

<comment><USER109> ^. just sends .

The ASCII page on Wikipedia does a good job of explaining what all these limitations are about. There's CSI-u mode, and I believe terminal emacs understands it if you enable it, but, yeah. There's a lot of legacy to support when your program is older than Unix.

</comment></comment></comment></comment><comment><USER149> The kindest thing we could do for future programmers is let Emacs and all tty- oriented editors die. There are much better options now. UI has improved a lot since the 1970s, let's embrace it.

<comment><USER150> I'm sorry, what?

Which modern editor has tools like SLIME or CIDER?

<comment><USER96> Genuine question: what's different about SLIME/CIDER than any IDE? Auto- completion, documentation lookup, REPL, code reloading, unit test integration... these are all in Xcode, IntelliJ, Eclipse, Visual Studio, etc depending on language support.</comment></comment></comment>