Toward a “modern” Emacs | Hacker News Reader

Toward a “modern” Emacs

lwn.net

286 pointslukastyrychtr523 comments

I don’t know. I read the whole article and it seems the suggestions boil down to emacs needing to be more “modern” by defaulting to dark mode, making color theming easier, changing right click behavior, the menus, and changing the shortcuts. And the author of the article would like the development process to be more “modern.”

Emacs is one of the most successful text editors of all time if not the most successful. It is widely used for a staggering array of tasks.

It is over 40 years old.

When I see a highly successful 40+ year old piece of software, my first instinct isn’t to ask what the people behind it can learn from me but what I can learn from them.

I’m not saying the editor can not be improved. But I think the bar is much higher than this. It’s not an insult to say something like emacs is not “modern.” Of course it’s not. And changing the colors? The shortcuts that have worked for decades? Please.

If someone thinks emacs will be more successful with these cosmetic changes they are welcome to fork it since this is one of the earliest open source programs. Code talks, a bunch of people opining on a mailing list is pretty worthless in comparison.

That's great and all, but people who are learning emacs for the first time don't know or care that it's one of the most successful text editors or that it's been around for 40 years. They care about being able to write code effectively. And emacs doesn't let users write code effectively by modern standards. Sure, after boatloads of configuration and tinkering it does, but it's unclear if it's worth it.

Forking it is also missing the point. There's plenty of forks with dark coloring schemes and predefined packages. Spacemacs, Doom emacs, etc. The issue is that most people hear about emacs and try to download emacs, not Spacemacs, not Doom. They're then greeted by an unfriendly UI and confusing commands and dammit it doesn't even autocomplete JavaScript by default.

Dark color schemes and proper right click functionality might seen dumb, but they're one easy step towards making emacs seem like an editor for the 21st century and not something your dad used on a Lisp machine in the 80's.

Yeah I think this is on point. The core maintainers are always kind of resisting changing things to more sane defaults, which is a pity.

I recently had the experience of a friend of mine, a data scientist, tell me he tried to use emacs but just couldn’t get it to work. When I asked how he installed it, he was like “well I just downloaded it, and started tinkering a bit with my config”. After which he just ditched it, he accepted that the learning curve was just to steep.

The idea that there are these whole starter packs never crossed his mind. I referred him to a few, and he suddenly got much more productive and has been a happy emacs user ever since.

Moral of the story: at the very least, users should be made aware of these starter packs much more prominently when downloading or installing emacs. Alternatively, fix the defaults.

I don't know dude, I've had new grads recently wholesale switch to Emacs just after watching me work for five minutes. "Holy crap, why are you editing these programs so much faster than me?"

Completely agree that out-of-the-box Emacs experience is NOT where it's at. I have twenty years invested in tweaking it to minimize keystrokes and operate faster for my use cases. Just remember that Emacs is not actually an editor, it's a Lisp Machine OS you can use to build an editor out of parts

Also keep in mind that alternate distros like Spacemacs are the way Emacs has to evolve, because making drastic structural changes to defaults would break so many user scripts and packages -- the things that provide most of the long-term value proposition of using Emacs in the first place.

Who cares if new people use it or if it looks modern? It’s working well for the people who want it. Not every piece of software has to be everything to everyone.

> That's great and all, but people who are learning emacs for the first time don't know or care that it's one of the most successful text editors or that it's been around for 40 years

I don't think this is true. In fact, I think most people that start in Emacs do so because they've heard that old experts use it, and know they will have to put some effort in to understand why.

> That's great and all, but people who are learning emacs for the first time don't know or care that it's one of the most successful text editors or that it's been around for 40 years. They care about being able to write code effectively.

I started using Emacs ~2008 and it's longevity has been a major factor in my decision, as I thought it would likely be usable for the next 30 years as well and help me to avoid changing environments every few years with each new hype.

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

I don't think nice color schemes are the point - although I do highly appreciate them.

I've tried Spacemacs and it's pretty nice. Using it in vi-mode, it provides multicursors that are far more advanced than in any other editor I know. Also it has a sidebar.

On the other hand for me Spacemacs is pretty buggy (macOS + Linux), I sometimes have to redo commands. Some important vim shortcuts are not implemented and the sidebar is also not always working as it should. Therefore I refrain from adding more plugins to the mix.

Experienced Emacs tend to not use the Spacemacs theme and are working with solid configurations. Maybe a rock-solid default configuration would work.

Then the solution is to just point people to some of the popular starter packs when emacs starts for the first few times. I think Doom is pretty rad by default.

> It is widely used for a staggering array of tasks.

Is it? What area are you in? In my hobbyist, college, and industry experience I've never seen anyone use emacs for anything. I have seen Vim (or at least vim bindings) a few times, but I only know of emacs from older unix discussions online.

Edit: Looking through stack overflow developer surveys, emacs use is in 16th place for editor popularity at ~4.5% usage, but has stayed close to that number for years.

Half my fifteen-person team at work (in a fast-growing mid-size fintech company in Chicago) uses Emacs, for editing/testing/running code in several languages, interacting with Web services, running various shells, calendar functions, document writing including UML diagrams and mathematics typesetting, and personal planning (Org Mode). To do this, we collectively probably use about 0.1% of the publicly available extension packages for Emacs on MELPA.

But the short summary is that most people use it for the various functions an IDE provides. The major difference between Emcs and other IDEs (VSCode, IntelliJ, ...) is that (a) it's often a little harder to get functionality that is provided out-of-the-box by another IDE, but (b) it's much easier (in some cases, infinitely easier) to implement workflows or functionality not already implemented by said IDE.

As an example, I often run snippets of code and want to insert the result directly beneath the code in question (similar to Jupyter in Python, but for any language, in plain text, directly in my editor). A trivial amount of Emacs Lisp gave me that with minimal effort.

If you like to have nearly absolute control of your editing experience, Emacs might be interesting to you. For most people starting out, who just want to get hacking on some code as quickly as possible, it is perhaps not the best fit.

Just to add links to the SO surveys mentionned here :

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

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

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

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

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

What's really amazing is vscode just appearing out of nowhere (7% in 2016, 35% in 2018). Blindsiding everyone. Cross platform, excellent to good enough UI/UX (very much inspired by Sublime Text but free), easily extensible in a widely available (and widely taught) language. For better or for worse.

The huge advantage of VSC: plugins can use HTML to implement whatever UI they want, from a workflow tool, to a test tool, to a Git graph view to a debugger data structure visualizer. And all that in widely-known to tons of people HTML/CSS.

Never understood why other editors, like ST, didn't give more UI options (checkboxes, buttons, dropdowns, a canvas, etc) to plugin authors. Consider how clunky a lot of plugin interactions with limited UI widgets available to them are.

But even if other editors started giving more freedom to design your plugin with more widgets etc, they could never beat the freedom HTML/CSS gives.

The second huge advantage of VSC: Microsoft behind it updating it non-stop. TextMate stalled, ST seems abandoned for long stretches of time (and it's not like we "already solved code-editing, what more you want") because of lack of manpower, etc.

The third advantage of VSC: first-class support for plugins, with "package manager" and storage built-in: plugin discovery, install, uninstall, enable/disable, configure, are all a click away. ST has this too, but not as refined as VSC, but more like a tacked-on text-based experience.

Two more advantages of VSC:

- remote development tools (MS). Code in your laptop, run/debug in SSH/Docker/WSL environment.

- automatically saved/synced preferences. This came in in this release.

I'm not in favor of Electron apps over native. But VSC is really that good.

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

VS Code is pretty much the proof that a modern Interface and beginner-friendly customization is the secret of success even for editors. Of course only additional to a solid foundation in terms of ability.

> emacs use is in 16th place for editor popularity at ~4.5% usage, but has stayed close to that number for years.

It is possible that "Stack Overflow surveys" select for programmers who tend not to use Emacs. For example, I use Emacs regularly and know what Stack Overflow is, but have never taken one of these surveys.

I'm not even sure how they survey developers. Ask on some crufty mailing list and you probably will get a completely different distribution from the one they showed.

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

Meanwhile, I’m always amazed how, on HN threads about Emacs, people talk about preferring the Vi family of editors. When I installed Linux on my computer two decades ago and had to learn *nix, my own (totally subjective) impression was that the Vi family was regarded as clunky and half-obsolete, about as much of a pain as editing in ed. As I began to contribute to the Free Software community, most of the other people I interacted with seemed to use Emacs. So, to find out that Vi is still used and loved in 2020 has been a shock.

When I entered a technical University in Spain, all the masters(teachers that have done incredible things on their lives) used either Vim or Emacs.

Most "normal" people just used other "more visual" editors.

As I learned from the masters I started using more and more both vim for unix tasks and programming and emacs for lisp. Now I use 65%vim, 30% emacs, 5% other editors.

Both of those editors are extremely powerful. But you need to know how to use them. It is not painful for the master to use them, in fact it is automatic and instantaneous and faster than any other editor, a thought becomes an action without conscious intervention, like you thing in playing Do minor in an instrument and your fingers do it automatically, you want to erase a line or replace a word, you think on it, is done.

They are like musical instruments. You could have the best piano or violin in the world, if a mediocre player plays them, you get bad sound.

Most people would be better served with a simple electronic piano or a tablet with lights that point to the next notes of the song, and auto correct them when they play a bad note.

I think the thing about Vi and Vim that has the most value in 2020 is not the software itself, but rather the keyboard-centric composable modal editing system that they popularized.

Some of the growth that Emacs has enjoyed over the past several years is from folks who want the Vim style modal editing in an editor as customizable and extensible as Emacs. Emacs "distributions" such as Doom and Spacemacs cater to these folks.

I came to vim (years ago now) because I was experiencing RSI from all of the chorded keyboard shortcuts I was using in Coda. Emacs doesn't help with that, but vim does (if you `map ; :`).

Any editor feels clunky for the first week of using it, Vim and Emacs most of all. Nobody wastes the headspace in staying current on multiple editors. So I don't know that you'll ever see an objective comparison of the two. But they're both solid ways to write code, it just takes way too long to get either one dialed in to do the things we expect modern editors to do out of the box, like code completion.

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

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

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

I know I fell into it because I originally learnt UNIX on shitty XENIX servers which were basically AT&T SVR4 on x86. The internet and Linux weren't around then.

Later on I had to work with a number of different versions of different UNIX platforms on a daily basis (Tru64, Solaris, HP-UX, AIX) as well as multiple varieties of Linux, and vi was a common denominator on all of them.

I've personally known 2 Emacs users in my ~15 years in the industry. I've worked in Europe for various startups and a bunch of corporations. Both of them used it as a sort of hobby/side editor, their main money maker was an IDE (VS, IntelliJ).

I've probably worked with 500 developers, if not more.

My personal impression is that Emacs is like the Yeti of programming editors. Everybody has heard about it, few claim to have seen it and even fewer still can claim to have proof of the sighting :-)

Is this a USA vs the rest thing? I've worked in many startups in the US and almost everyone uses emacs. Last few years, VSCode has been getting popular though. I had a similar experience when I was a student in UC Berkeley, although it seems like there were more vim users in school than in industry. Anyway, pretty much all my current coworkers use Emacs and I work in Boston, MA.

Personally: I cannot imagine programming without emacs, to me programming is so strongly associated with emacs...

Of course, I also understand that it's all personal preference.

It has definitely been this way _as far back as I can remember_ (at least the last two decades).

There have always been popular tools. Most of them haven't stuck around though.

Emacs has.

I wouldn't recommend using it right away though. Instead, I'd recommended accumulating some pain by using other popular editor-like,workflow-like,manipulation-like tools, because that might be the only way to appreciate what Emacs brings to the table.

(though I have to acknowledge VSCode's achievement, gaining massive adoption in what has always been a fragmented space)

In my uni, many professors used Emacs when demonstrating. For example, one course [0] used the Agda language [1] as a proof assistant. Afaik, the only good interactive Agda interface is the Emacs Agda mode [2]. Maybe you just live in a region of the world that happens to have a weak culture of using Emacs?

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

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

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

I use emacs for everything. I'm a hobbyist and computer science major (sophomore, undergraduate). Hell, I use emacs to edit the markdown that gets rendered to a predefined Latex template for my philosophy classes!

org-mode and magit seem to bring in a lot of emacs users, even if they're only using one of those two things. If I stopped using emacs for code tomorrow, I'd still use org-mode and magit and still encourage others to do so as well, even if I also pushed a different editor or IDE for writing code.

I've worked with many programmers who use Vim, although I've personally never grokked it.

I've used Emacs for years for editing/programming, running shells and reading news/email.

I've attended two universities in the UK and it was used by default for some of their programming/computational courses; this was in different departments (Physics and CS), a decade apart.

Emacs has been used to build user interfaces (e.g. ProofGeneral, which was the de facto interface for theorem provers like Coq and Isabelle for many years).

Some programming languages de-facto assume they're being written via their Emacs mode (notable Agda; similar to how some JVM languages assume they're being written in Eclipse or IntelliJ).

Years ago I inherited an academic research project which happened to be written entirely in Emacs Lisp.

I think it hugely depends on the programming languages one uses (or used to use), as well as personal history. For example basically everyone learning lisp was, for a long time, encouraged to use emacs (I think this is still the case for Common Lisp but I’m not sure about other varieties). This makes for a pretty unpleasant lisp learning curve as most people are not already familiar with emacs. Other functional languages in the ML family may not be very similar to lisp in many important ways but because their lineage went back to lisp people and environments, emacs ended up usually being the editor with the best support, though this is less the case these days.

If one looks at computer history there seem to be several versions of a cycle that looks like “crap underpowered computer slowly gets more features and better performance only to become outnumbered by a smaller slower cheaper computer.” Depending on where one fell in that cycle, emacs may not have been an option (eg if you were starting programming on dos or an early windows you likely wouldn’t be using emacs. If you were starting at the same time using a Unix workstation, emacs might be a reasonable or recommended choice).

During the early naughties you were probably using windows and not exposed to emacs unless you worked on Unix/Linux based web backends.

I've used emacs ever since college. I've tried a bunch of IDEs, VSCode, Sublime, Atom, even vim. They just never felt as comfortable as emacs in the terminal.

I'm probably in the minority since, despite a decade-plus of use, I'm by no means a power user. I use a little bit of org-mode and babel here and there. I can hack around in elisp if I want to tweak a mode. But that's about it. To be honest, I don't even compile code or navigate the directory tree from inside emacs.

That being said, two reasons I don't think I'll ever switch. One, the key bindings and commands just feel more elegant. Don't know if that's because they're locked into my muscle memory, or they're genuinely better. Two is that I live in the terminal. IDEs are great, but I much prefer just piping find to grep to sed or similar bash-fu, when I need to do something fancy.

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

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

Heavily language dependent. I used nothing but Emacs until I switched over to Java, where IntelliJ is king. The level of Emacs usage I’ve seen depended a lot on what language was being used, it seemed much more popular for Python users than Ruby, for example.

but how is % usage related to tasks ?

Nov.el is my favorite ebook reader.

The hypothesis that Emacs is used for many things is consistent with the hypothesis that Emacs usage is rare. This is because many humans have existed over the years, so a staggering array of tasks can be addressed in even a small fraction of those person-years.

> When I see a highly successful 40+ year old piece of software, my first instinct isn’t to ask what the people behind it can learn from me but what I can learn from them.

This is how incumbents die: when the fact that something has existed for a long time is taken as proof of it being at no risk of disappearing.

I used to work for a company that has been around for roughly 150 years. And it is precisely the attitude that "we've been around for 150 years" that made it blind to the fact that in the last 15 years, it has become a little bit less relevant every year because disruptors slowly eats away its market. In one sector the company would boast 3% growth year over year - while glossing over the fact that the sector had a growth of several hundred percent per year. You can have growth and at the same time lose market share at an astonishing rate.

This is kind of what happened to Emacs. There has been an astonishing growth in the number of developers over the past decades. Which means the "market" for editors and IDEs has exploded. And while more people may be using Emacs today than ever before, I would hazard a guess that the market share has gone down.

I agree that age is an issue since design decisions were made before standards were agreed upon, and it is going to be very disruptive to change those design decisions. Changing keybindings is certainly going to cause pain, but even remedying terminology is problematic (e.g. window vs. frame). That's likely why cosmetic issues were popping up as potential solutions.

I agree that those cosmetic changes won't modernize Emacs in a meaningful way since it is a very low bar. I also think the article is correct in pointing out that discoverability needs to be addressed. Contrast Emacs and VS Code in terms of extensions. Both editors are intended to be extended. VS Code does a good job of highlighting extensions, while the Emacs extension manager is buried. Likewise, Org seems to be rather popular yet very people will discover it independently since the user interface isn't designed for that.

That said, some of the discussion about discoverability was disheartening. Telling people about features isn't really sufficient. They need to be exposed to it while they are working with the program, and that exposure has to be in a non-disruptive way. Tutorials, video or otherwise, aren't going to help because of that. There are plenty of Emacs tutorials online anyhow.

If the LWN article is an accurate reflection of the discussions, I think that Emacs developers have to put a lot more thought into how to progress.

I feel old when I see ”modern Emacs” and think “Oh, maybe they are finally either finishing off Guile Emacs, or porting the extension language to Common Lisp”.

I guess I agree that ibuffer should be part of the standard distribution. Less sure about undo-tree, but could be an option if the authors released it under appropriate licenses (I understand that contributing code to Emacs is somewhat cumbersome; although if I were smart enough to do so, I would jump through the hoops in a heartbeart).

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

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

It's over 40 years old but it has fewer and fewer users younger than that. VS code is rapidly taking over it's niche and without modernization, of many kinds, emacs will die out in a generation.

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

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

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

For comparison of numbers and growth rate: VS Code was new in April 2015, had a claimed 2.6 Million active monthly users in Nov 2017[1], became the most popular editor in StackOverflow's user survey in 2018[2] with 34% of respondants and again in 2019 with 50% of respondants, to a claimed 11 million users in 2020[3]. Its codebase has been forked 16,000 times[4].

In 5 years, VS Code has gained more users than the population of Switzerland, than the population of London, than Uber has drivers. I'm not suggesting Emacs ought to chase maximum popularity, but if there was any feeling that "the editor / IDE market was saturated" or "there was no demand for editors", that doesn't seem accurate.

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

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

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

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

I've used Emacs for 33 of those 40+ years, and I agree with that until the word "without".

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

In a generation, vim and emacs will still be around with their minuscule but loyal user bases of tinkerers and VS code will have long been replaced by something newer and flashier.

The default display colors for software have gone from green text on black background to black text on white background, and then back again in the 40 years that emacs has been on the scene.

It’s quite silly to think that dark mode is a modern invention. It’s just a example of how software trends are a form of fashion, and they do behave cyclically.

See also: return to lightweight clients and fat servers as we moved onto the web, and then moving the bulk of work back to fat clients with React etc

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

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

I think we're talking about different things here. You're talking about the physical restrictions of the media, I'm talking about the defaults selected by software developers.

My first computer could display dozens of colors, but defaulted to a dark background and light text. Windows 3.11 defaulted to black-on-white, on hardware from the same era. And now we're cycling back to defaulting to dark modes again.

There is this one concept. I can’t get away from it. Comprehension bandwidth. Emacs is an amazing piece of software. I have probably used it more than any other piece of software over 20 years. The marginal utility of Emacs over pycharm or Gedit does not exist. Most programmers, if they are being honest, can be just as effective in notepad. Modern IDE that understand their problem domain provide much more utility. These are simple facts. We type characters, they do stuff. It don’t take a fancy editor to do that.

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

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

No, there are certain features and terms in Emacs which makes it very alien to the modern world. Things like the cursor being limited to the visable part of the buffer, the usage of "window" for a buffer and "frame" for an application-window. Also the way Undo/Redo works and such.

If you really aim for a modern Emacs, then forking it and fixing it from the ground up might be not the worst idea longterm.

Emacs is so old that it has accumulated quite a number of old cruft and debt.

So I agree in part with your point that emacs doesn't really need to change their UI/UX (new menu, new shortcuts, etc). The Emacs model takes time to learn and is different from the rest of the world, but it works quite well once you take the time to learn it. That's not for everybody, not necessarily beginner friendly, but that's fine, emacs is a quite advanced editor environment, it has its own niche of users.

But some things make emacs just a bad editor, even for people who did spend the time to learn it. For example emacs is horrible at dealing with big files. The entire editor is stuck for seconds if you open a log file with just a few megabytes of content. Emacs performances are also really bad when compared to other editors, simple syntax highlighting or intellisense is just really, really slow.

I used emacs for years as my main editor because I was happy to have something stable, because I love lisp, and because I really like the introspection and control you get. But at some point I realized how fast and way more advanced other editors were in comparison to what I could get with a tuned emacs environment and jumped ship.

Even keeping the emacs UI and UX there is a lot of modernization that can be done under the hood to make it up to the task of the modern world.

I just tried opening a large (11 MB) log file on a 2008 netbook and, except for the unexpected "File is large, really open?" question, the load time seemed instantaneous (Emacs 26.3, Lubuntu 16.04).

Even if they are not enabled by default, I think having these features would be nice and would be helpful for emacs distributions to really take off more than they currently do.

Something like spacemacs and prelude would have a much wider adoption if there was a mode that can be enabled to make the learning curve smaller, the look / themes better, ui more intuitive.

The author seems to confuse "better" and "more like others". The colors are a clear example of the latter, the developers didn't choose a light theme back then because dark ones weren't invented yet or because computers weren't powerful enough for them. Things like the completion UI may be a different story.

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

I don't think emacs needs to change but I also feel like there are some concerns that need to be addressed for a new and rapidly growing generation of programmers who aren't learning to use emacs and vim. While it might be thriving now, we're probably 10 or 20 years away from emacs being extremely niche (more than it is today).

I would like it to be multithreaded and for Org mode to have some more UI features (and I think a lot of people would - at least the former). From what I understand it's really hard to do that by building on the existing C base ELisp base.

Unpopular opinion: we should write the "new" Emacs in Julia (and maybe Rust).

As for Julia, I mean I like the matlab like syntax for data science use, and I’m sure its great for prototyping computation heavy algorithms where run time dwarfs the JIT lag, but its surely not suitable for a text editor, at least at present. I’ve tried Julia several times as new versions of have been released and for simple scripting tasks that required a few external libraries I’ve always ended up rewriting the script in Python because the scripts were faster to run from start-up, more consistent in performance (no unexpected pauses to re- pre-compile) and simpler (no messing around getting packagecompiler.jl working etc).

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

Define success.

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

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

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

Just not on your lifetime.

The main problem with emacs is that while it's praised for being a programmable lisp environment, it's not a really good one.

It doesn't have widgets, decent rendering engine with scene graph and hardware accel, it's single threaded, the language is clunky. You really can't make decent applications in emacs, only text with embedded images and primitive buttons, that blocks and stalls all the time.

It really needs some major update.

I don't think Emacs needs to be GTK

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

But the funny thing is Emacs has neither of those. There is no real "API" or "plugin system". Just code. You can copy a function off the internet and paste it into editor and now it is part of your Emacs. And you can modify any of the existing code as much as you please. That is the lesson of Emacs.

transparency, gradients and rounded window corners.

oh, and a thin sans-serif font.

maybe a soundtrack

Can we move Emacs into the cloudchain somehow?

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

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

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

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

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

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

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

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

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

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

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

From the Emacs install instructions:

"Nonfree systems

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

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

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

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

Windows

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Nope, it's the ecosystem around them.

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

But Windows IS evil...

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

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

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

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

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

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

M-x find-file-literally

What is this supposed to change?

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

Emacs has packages too: M-x package-install

Or install & configure in .emacs:

    (use-package projectile) # :ensure is enabled

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

But what if you're wrong?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

To add packages, but to remove them...

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

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

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

M-x list-packages

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

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

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

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

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

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

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

Historically, el-get e.g.:

  (el-get-bundle ace-link)

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

What’s extending VS Code like compared to Emacs?

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

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

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

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

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

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

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

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

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

https://github.com/bbatsov/prelude

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

Thanks! I had forgotten about Emacs Prelude.

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

But Doom Emacs presents itself as:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

A lot of things are different without being better.

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

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

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

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

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

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

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

A small (incomplete) list of real problems:

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

- Performance issues on long lines of text.

- Architectural/technical debt.

- etc...

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

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

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

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

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

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

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

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

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

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

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

That was touched on in the article:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Upgrading to 27 made no difference for me.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Emacs is really fun.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

So... what should my next steps be?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

There is surprisingly little research on this.

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

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

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

https://emacsthemes.com/

This really doesn't seem that complicated.

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

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

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

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

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

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

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

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

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

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

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

Does Emacs need a new Lisp?

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

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

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

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

As always Stallman maintains a ludicrous level of self importance.

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

Some pros:

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

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

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

---

Cons:

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

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

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

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

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

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

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

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

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

(This probably even exists somewhere?)

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

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

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

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

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

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

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

https://github.com/masm11/emacs

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> then you trigger whatever command you need

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

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

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

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

In helm: shortcuts are shown in the result list:

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

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

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

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

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

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

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

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

It’s in a public git repository

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I still edit config files etc with vim though.

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

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

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

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

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

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

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

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

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

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

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

> They were standard when Ronald Reagan was president.

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

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

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

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

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

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

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

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

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

I said:

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

And you respond with:

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

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

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

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

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

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

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

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

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

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

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

M-x cua-mode<return>

Oh, and you're welcome.

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

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

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

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

Market share shouldn't matter.

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

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

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

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

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

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

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

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

> A lot of the popular DOS applications

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I am one of those geezers.

Another geezer here. Using Emacs since Bush I.

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

Obviously they don't work in terminals.

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

Here are my beefs though:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Making it easier to set colors sounds fine to me.

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

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

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

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

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

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

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

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

* VisualBasic (HS)

* Emacs/R

* Spyder

* PowerBuilder/Emacs

* PyCharm

* SublimeText

* Visual Studio Code

* Emacs (but now full time)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

References:

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

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

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

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

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

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

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

It feels like vim is finally winning?

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

intellij for java, emacs for everything else

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

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

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

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

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

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

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

Oh look. It's THIS thread again

Reply on news.ycombinator.com