Hacker News new | past | comments | ask | show | jobs | submit login
Emacs Modernization: Simple Changes Emacs Should Adopt (2006) (ergoemacs.org)
112 points by AJRF 23 days ago | hide | past | favorite | 169 comments

I posted a link here to a Reddit post that said “if you could change one thing about emacs what would it be?” It had almost 200 comments. Some answers definitely touched on these points. But for the most part, what Emacs users wanted was for the Gnu Emacs maintainers to do was…

1. Switch out Elisp for a Common Lisp or Scheme

2. Update the way Emacs Ui Core so it used standard GTK or something better. (The current implementation uses a lot of ugly hacks to support a subset of GTK)

3. Ability to scroll without bringing point along with me so I can quickly check something off screen then just continue typing where I left off.

4. Improve threading so that things like TRAMP didn’t freeze when you were connecting

5. Fast/Arbitrary graphics support

I think for most Emacs users it’s a performance thing. Though the improvements to the GUI code would go a long way to making it easier to make Emacs be more user friendly.

In terms of this article. I think all of this is possible in a separate distribution of Emacs right now. Emacs will never turn on most of these things by default. But maybe if a version of Emacs that makes these changes becomes wildly popular, the current maintainers would be more amenable to it.


Yes, if you ask people who know how to use emacs what they would change, the answer is going to be very different from the answer you’d get asking people who have tried to use emacs and gave up.

The documentation does really suck. The terminology makes no sense to users not used to it. It does not explain that to make this into a functional system, some configuration needs to be done. It is terrible out-of-the-box. ‘Because this is how rms did it 45 years ago’ is not really a good excuse.

The documentation does _not_ suck. It it literally the most well documented software in existence, a reason for which it has been used for many different things outside its original purpose of text editing.

Yes, it may not be for everyone. But just say that, that it uses certain conventions that are likely outdated for a reasonable set of the population. But you can't say the documentation sucks when you have the below:



That documentation is thorough does not mean that it is good.

If anything, one might argue that Emacs documentation being so extensive while buing built around idiosyncratic conventions makes it worse, not better, for many cases: it means it is even harder for people to actually find relevant parts of the documentation.

Emacs itself is idiosyncractic. Being cute and using "standard" terminology would just confuse users.

This must be the funniest way to justify archaic terminology I've seen so far.

`You can also type Meta characters using two-character sequences starting with ESC. Thus, you can enter M-a by typing ESC a. You can enter C-M-a (holding down both Ctrl and Alt, then pressing a) by typing ESC C-a. Unlike Meta, ESC is entered as a separate character. You don’t hold down ESC while typing the next character; instead, press ESC and release it, then enter the next character. This feature is useful on certain text terminals where the Meta key does not function reliably.`

Taken from: https://www.gnu.org/software/emacs/manual/html_node/emacs/Us...

I'm really not sure that this counts as 'well documented'.

How would you phrase it? I find it to be quite clear.

Agreed. The paragraph above it explains that Meta is probably the alt key.

The terminology itself is kind of a relic from the past (it's gotta be Alt on 99.9% of emacs users' systems), but it's explained very clearly.

Emacs is the self-documenting editor for a reason. I always found the documentation very good. I submit that every sufficiently complex system will need some terminology specific to the system the user will have to learn. Not wanting to do so if a form of lazyness that the developers cant really do anything about.

Dude, Emacs had its own terminology for text editing, the rest of the world moved on, another terminology won.

If Emacs would be solving protein folding, I'd maybe understand the need for unique terminology, but this is just unnecessary smugness.

At this point Emacs is only doing a few user facing things which are unique, and I'm not even sure about those.

I have many times submitted jobs related to helping solve protein folding from within Emacs (shell buffers). It helps a lot to have the editor operating on the shell inputs and outputs.

You really didn't get my point, did you? For new research, protein folding was a random example, you need new terminology which everyone just accepts and uses, it becomes standard.

Emacs sort of tried to do that, failed, and now it's like Australian animals faced with animals from the rest of the world. It will never win, it should adapt.

I think that Emacs solved a lot of important problems before others did. The rest of the world decided to reinvent and rename things, and they popularized some of these things. Emacs held its ground, so now people who transition to Emacs from a different background might be confused. Emacs documents everything thoroughly, so it might take a whole weekend of reading to catch up and be productive. I think that Emacs is worth this extra time. The real number of confusing terminologies or technologies are probably only a dozen or two. And then there are hundreds of common concepts with a powerful implementation in Emacs. And some things that you still can’t do as cleanly with other tools. Especially things you’d need in cutting edge research.

SInce you mentioned "unique" features, Emacs is the only programmable editor which works mostly the same in terminal and GUI mode. You can write extensions (in elisp) which largely dont know about the UI used by the user. So you actually can write UI-independent programs in elisp. I dont know a single tool that got this right. Sure, you're going to tell me that termianl isn't relevant these days, and everyone has moved onto windowing systems. Yes young padawan, that might feel true to you. You will understand one day.

Emacs is great out-of-the-box.

Really its only problem is the annoying bugs you frequently run into. (Emacs Lisp really isn't meant for programming large, stable systems.)

> Emacs is great out-of-the-box.

Sure. And because the out-of-the-box is so great: 1. people actually create emacs distributions(!) like spacemacs, doom-emacs, etc. 2. the emacs wiki has https://www.emacswiki.org/emacs/DotEmacsBankruptcy

Emacs is so great out-of-the-box that, unless you're in a terminal, every time you launch it to edit a file, it will take up half its window with a welcome message, until you specifically create a configuration file to disable that. This is particularly frustrating if you just want to use it with its default settings, eg, as root to edit a file.

It's clearly not intended to be reasonable usable without user configuration.

If Emacs is an OS, then of course there should be different distributions of it.

That's like complaining that Windows is broken because it doesn't come with MS Office out of the box.

Except Emacs is just a subset of the whole experience.


> Emacs is great out-of-the-box.

"Slackware is friendly. It's just really picky about who its friends are."

I mean, I'm sure there are like seven, maybe eight, people in the world that think Emacs is great out of the box. Where we run into trouble is that most of those seven or eight people are the ones deciding what Emacs is like out of the box.

M-x shortdoc-display-group is quite nice.

> ‘Because this is how rms did it 45 years ago’ is not really a good excuse.

Not only do they use it as an excuse, they think it means Emacs is somehow enlightened. The people that want that can put (setq rms-mode t) in their .emacs and let the rest of us have sane defaults.

I've been using Emacs for more than 20 years, these are all (for the most part) non-issues, brought up by folks who either are new to Emacs or never read the documentation / dived below the surface.

1. Emacs Lisp is great (for the problem domain), exists and works. Common Lisp could work but then given how close Emacs Lisp and CL are, there's no clear benefit, especially with Emacs getting native compilation. Scheme was proposed, some POC code written and failed because nobody was interested. It doesn't fit and fragmenting one of Emacs's greatest strengths (consistent ecosystem of working Emacs Lisp code) is a terrible idea.

2. The Emacs UI core is completely toolkit-agnostic. It doesn't use GTK on Windows. It doesn't use GTK on macOS. You can run _graphical_ Emacs without GTK or any toolkit whatsoever on Linux, and not lose any functionality. Therefore what you write makes no sense (ugly hacks to support a subset of GTK).

3. There are multiple ways to do this. Read up on setting the mark.

4. Threading has nothing to do with TRAMP freezing, bad configuration does. TRAMP documentation (does anyone that bring up these points ever read it?) has multiple sections on improving performance. Check "SSH control master" and "Improving performance of asynchronous remote processes".

5. SVG support is already there and more is on the pipeline.

What I've noticed during my 40 year computing career is that folks get lazier and lazier. Few read manuals / documentation anymore but most are quick to jump to superficial conclusions without any substantial time investment in trying to figure things out. Spoonfed knowledge is the order of the day, and the folks doing the spooning are usually not far from clueless themselves (the blind leading the blind). This leads to generational gaps and rapid propagation of erroneous ideas amidst the newbie masses, very similar to what you laid out.

Emacs mastery requires commitment and time investment in order to understand (at least) the basic models and the trade-offs involved. If that doesn't take place, one can start going down paths that are entirely irrelevant ("Emacs needs threads so that it doesn't freeze!", "Let's use JavaScript so we can do non-blocking IO!", "Let's rewrite Emacs in Rust!")

> What I've noticed in my 40 year computing career is that folks get lazier and lazier. Few read manuals / documentation anymore but most are quick to jump to superficial conclusions without any substantial time investment in trying to figure things out.

The problem is being used to software that "just works".

I've tried out to figure out how to to stuff with Emacs multiple times, but apart from sticking with org-mode for some use cases, I always have up after a while.

I don't see why I should "master Emacs" when there are usually better tools for any given task.

I resisted switching (from vim to emacs) for a long time, but it's just not true that "there are usually better tools for any given task": magit and the other git integrations in emacs are significantly better than the equivalents in VSCode or IntelliJ (anecdotal, but I've never had issues figuring out version control in emacs whereas I've made significant messes trying to use the VC features of VSCode and IntelliJ); the ad-hoc programmability of emacs is second to none (just the other day I whipped up a quick one-off refactoring tool to fill in names missing in the LSP diagnostic errors: other editors might have an equivalent feature, but nothing makes it as easy to combine features in ad-hoc fashions as emacs). notmuch is, so far, the best email interface I've found. And, I could go on: I've occasionally tried switching back to "normal" editors, but each time I find that I'm missing some configuration that was trivial to put together in my emacs configuration and is only available in my new editor if I'm willing to make significant compromises.

Emacs is a tool with an enormous set of available functionality that has been continuously developed for 35 years. Moreover, its major strength is its programmable and nearly infinitely-extensible nature.

And yet, it does "just work", from the moment you first run it -no previous experience needed- it does present you with a familiar "editor skin". It does offer you an interactive tutorial. It does come with comprehensive offline documentation. It does come with the best interactive querying and documentation capabilities of any software system in wide-use today.

So, taking all of that into account, when you say "just works", I read "I don't want to spend any time whatsoever to learn 35 years of features and a software system that is by far the most user-empowering in existence today". Your loss.

> It does offer you an interactive tutorial.

:facepalm: Yeah, my 8 years old niece will be taught "Informatics" in the school. Starting in a few days, actually. I'm sure she will enjoy Emacs over Notepad, since Notepad doesn't have any interactive tutorial.

> It does come with comprehensive offline documentation.

To avoid using precisely that, some years ago, I created myself a little extension of the engine-mode which opens up a browser and searches on the internet using a proper search engine. Here's the code: https://github.com/Bost/dotfiles/blob/c262e4dd7c5a498ce5d75c...


> It does come with the best interactive querying and documentation capabilities of any software system in wide-use today.

I managed to learn how to write my own plugins, macros, spacemacs core extensions, etc. I hope one day I'll learn how to use the emacs interactive documentation, too. Eventually.

Emacs is definitely not a SW to use if you're not going to read the docs. There's no good argument that Emacs should be, especially given what you say:

> I don't see why I should "master Emacs" when there are usually better tools for any given task.

I use Emacs for all kinds of things - not just programming. If I pick any one, there's definitely a better tool out there. Emacs's strength is the ability to tie it all together. If all a person wants is a good text editor, I would not recommend Emacs to them. Emacs is one of those things where you get more out of it the more you invest in it.

And it's totally reasonable to decide not to invest in it.

I guess that's what might be the difficulty for newcomers: having an idea of what exactly I could use Emacs for that justifies the high upfront investment compared to other tools with a more familiar UI.

Doom Emacs and other distros are great because they allow to just dive in with minimal configuration effort and sensible defaults. Without it, I certainly wouldn't have started using org-mode.

It shouldn't be necessary to learn a programming language and spend hours with the Emacs documentation just to be able to use some of the great packages like org or magit.

> It shouldn't be necessary to learn a programming language and spend hours with the Emacs documentation just to be able to use some of the great packages like org or magit.

It isn't. You could just go through the included tutorial for Emacs, and watch a tutorial for org, and you'll immediately be productive in org.

And you definitely don't need to learn elisp. I was a power user for almost a decade before I learned elisp. The most I could do was use setq.

The point of my comment was that one can easily be productive in Emacs, but if you want to do things that set Emacs apart from other tools, you'll need to go further and read more docs. Someone could learn just the basics and write documents/code with Emacs fairly quickly. But those people will continually ask "What's the point - I could just use an IDE which follows semantics I'm used to."

Doom/Spacemacs are great - just not for everyone. It's good to have them around, and it's good to have better defaults in vanilla Emacs. However, there are a lot of config choices they made that I guarantee would have turned me away from them as a newbie.[1] They are a lot more opinionated than vanilla Emacs, and would likely turn off as many new users as they will attract.

But it's good to have more options.

[1] For one, I could never wrap my head around vi keybindings - and I tried them before I tried Emacs.

2. What you wrote makes no sense. If linking to gtk provides nothing at all, why is the code even there?

3. Why is the default config for TRAMP so bad? It isn't spoonfeeding for everyone to not want to reconfigure it.

2. It makes perfect sense if you actually learn how Emacs works. It provides superficial elements like GTK-look-and-feel (scrollbars, menubars). Most Emacs experts disable all of these anyway, thus nothing of value is lost. On the other hand, toolkit-less Emacs tends to be a lot more stable. That was definitely the case for GTK since it had well-known bugs that the GTK developers refused to fix that would crash Emacs. I suggest you compile graphical Emacs on Linux without any toolkit (or with Athena/Lucid/Motif) to see for yourself.

3. Because there are trade-offs involved and the (informed) user should be responsible for enabling them.

The fact there are known workarounds for certain problems shouldn't prevent us improving and fixing the underlying causes (in a step-by-step, backwards-compatible way).

With that said, I'd rather not see Emacs go all-in on threads or GTK, since they generally feel like WorseIsBetter anti-patterns:

- GTK 2 seemed OK, but unusable for me due to the 'display disconnection' bug. GTK 3 is full of red flags: a constantly moving target, little thought given to third-party applications, pretty much killed off third-party theming, etc.

- Threading is famously error-prone, which is completely unnecessary for high-level languages like Emacs Lisp. Co-routines, async/await macros, delimited continuations; even an actor model would all seem like better fits.

GTK3 is actually feature frozen, it's not a moving target. Development has moved to GTK4. Also, it has always supported third party themes, however the convention is that they were always considered unsupported because they can break apps.

Similar age, back in 1995 XEmacs was my refuge, because most UNIX world was foreign territory for IDEs and developer editors like Ultraedit.

With the way UNIX landscape evolved, I seldom use it, although the last time I used it in anger was around 2006, the muscle memory is still there, but really, the IDEs I missed in 1995 are now available everywhere.

Be aware that this are comments from people who use emacs. It does'nt mean that implementing these wishes will also lead to more users coming to emacs. Even the low hanging fruits from the article are barely something that will bring in new users.

Though, distributions like spacemacs and doom-emacs have shown that they are bait working well to get new users. Investing more in that directions should pay out to some degree.

Hopefully pure-gtk branch will be merged prior to Emacs 28, addressing (2).

On (1), I'm not much of a programmer, but Emacs-lisp fine, so I'm not sure what benefit changing languages could bring.

There are a good number of Emacs users who also use a Lisp dialect such as Scheme for their day-to-day work. Emacs Lisp has enough small, slightly strange differences from more mainstream Lisps that I can imagine that being kind of frustrating.

For myself I think that Emacs Lisp is a pretty good language for configuring a text editor. A lot of its warts actually make it easy to use in that context, in my opinion. Personally I wouldn't mind moving closer to Scheme or CL. Though I wouldn't want to lose "special" variables (with dynamic binding) no matter what happens -- they're a key tool in tweaking behavior to get it just how you want. But for people who are trying to build packages, especially large ones on the order of Org or Magit, I can see having a more, let's say production code oriented language, being a nice prospect.

Emacs Lisp now arguably has a better type inferencing compiler than SBCL[1].

[1] http://akrl.sdf.org/gccemacs.html#orge596749

Would this pure-gtk branch avoid GTK's famous X11 connection bug? https://gitlab.gnome.org/GNOME/gtk/-/issues/221

Every few years I'm tempted to try the GTK version of Emacs, but it doesn't take long before this bites me and I go back to Lucid!

Is the pure-gtk-branch really working on switching the underlying UI-architecture? Or just removing the hacks for X11 and moving them to gtk?

pure-gtk doesn't decouple ui process from editor, if that's what you're asking about.

No, I mean emacs was designed for terminals. The whole GUI is build ontop of this and is suffering from it. Is pure-gtk changing this and decouple from the terminal-design or still working with it, replicating the same hacks just in a different GUI?

Sorry, I just don't understand. I don't really use terminals except to do a system update. Is there a specific issue?

Terminals work with characters, meaning, lines, columns, fontsize. GUIs usually are working with pixel, meaning x/y-coordinates and free sizes.

In case of emacs this means there is a bunch of hacks to translate pixel-coordinates to line/column-coordinates. This often are working well enouhg, but sometimes not. For example, with my emacs there is always a free space at the bottom when maximising the window, Resizing the window also works in terms of lines, not pixels. Positioning of completion-dialogs is linked to chars, not the pixel-coordinates of a the word which in certain cases get's ugly.

It's overall not what I would call a hard issue, but still ugly. But it also kinda limits what you could do with Emacs in GUI-world. As Emacs has no understanding of z-axis, there are overlapping widgets and free-positioning of elements outside the text-flow.

An additionally, it seems the too many laysers and additional complexity has some speed-impact in GUIs which the terminal-version has not.

FYI There /is/ `frame-resize-pixelwise` and `window-resize-pixelwise`, to help with a few of those issues.

It also doesn’t offer smooth scrolling on macOS except in a third party port.

I've seen all these before and it makes me wonder why someone doesn't just make a different version of emacsen like guile-emacs. There must be a lot of inertia behind emacs and substantial amount of development effort to make all these changes that keeps competitors to gnu emacs from progressing to replace it.

Because of GNU Emacs biggest strenght, which is also it's biggest flaw: the mountains of existing code. Any new emacs must support what emacs already offers. And this means not just to be able to run the code, but to also support the huge amount of special and exotic features that Emacs offers. Guile-emacs for example has a pretty long history on fighting emacs-strings and it's special features.

There is the general believe that users don't wanna change from emacs away and any new emacs should be ~100% compatible to old emacs. But history has shown, people will not settle with inferiour clones. So many work will be neccessary, whatever someone will build to replace emacs.

> 3. Ability to scroll without bringing point along with me so I can quickly check something off screen then just continue typing where I left off.


> 4. Improve threading so that things like TRAMP didn’t freeze when you were connecting

You really want this, as well as the low level functions to support TRAMP to be written in C.


Regarding 3. Ability to scroll without bringing point along.

You can duplicate the buffer side by side with the original buffer and in each window point will be at a different location. This is fundamentally just better than such a peek mode as you can see two different segments of the same file side by side. If you do want to peek and return you can use goto-last-change to return to where you were last typing. In evil this is bound to g; no idea about a binding in plain emacs but nothing is stopping you from using and binding such a thing.


You can also use marks in evil m[a-z] to set a mark '[a-z] to go back to that mark. so for example ma 'a to go back.

Consider the alternative. Since you don't want scroll to always leave point behind you must have a special binding to enter peek mode and thereafter you scroll as normal. Then one of two things has to happen. Either you decide point really ought to be here now and you have to hit a key combo bound to end-peek-at-current-location or another key bound to end-peek-return-to-point. I would suggest escape/q for end-peek-return-to-point and return for end-peek-at-current-location. You can also do end-peek-return-to-point if you just start typing obviating the need for an additional binding but I think this would be a little weird because there would be a slight hitch while it pops back to prior location.

The biggest defect with this compared to goto-last-change is that it is ironically given the alternative being part of evil modal. You have to decide to use peek ahead of time and then you have to remember you are in that mode and do something to get out of it should you decide you actually want to do something different like exit with point at the new location. With goto-last-change you don't have to decide ahead of time you can simply decide to go back after the fact without needing to attend to any state in between.

Multiple windows on the same file and marks require attention ahead of time but are far more general and powerful than peeking.

Sometimes what people want and what is most useful are different things. Fortunately Emacs is simple enough and powerful enough for you to implement peek mode trivially if you like but I don't think it would be worth using compared to the alternatives. Logically you could implement it by remembering present point and making local bindings to go back to prior point example esc to go back enter to remove local binding to esc.

>You can duplicate the buffer side by side with the original buffer and in each window point will be at a different location.

I actually attempted that last night. It doesn't work unless you disable completion frameworks like company/LSP because as soon as a completion event triggers, both buffers snap to the completion location.

this is very odd. I both routinely have duplicate buffers visiting the same file and use LSP with company mode. I have never seen the snap effect you are describing. Why would completion trigger in both buffers? Maybe it is company vs ac-mode or some other completion system?

I use company with lsp. Perhaps it's dependant on language (server)? I was hacking some Go at the time.

I just tried it, can't reproduce. I'm programming in C++, so different server, but lsp shouldn't really care about the actual upstream server.

How do you open the second buffer visiting the file?

I was unable to reproduce this just now in emacs 26.3 using company/tide. I've been thinking about moving from tide to LSP, but that bug would drive me crazy so maybe I should wait for it to be fixed.

We haven't established that the bug isn't specific to users configuration.

Just tested this with company in a clojure buffer and did not observe this. I would suggest that something else responsible for the effect. Do you have any idea what causes this?

You are probably visiting the same buffer in a different window. What you want is clone-indirect-buffer-other-window.

To me this seems like the answer. We don’t need to change the way emacs works, we just need a standard way to do this that is familiar to people coming at emacs from other environments.

> 3. Ability to scroll without bringing point

You could probably do this with a transparent indirect buffer with a special “scroll only” mode that reverts once you start typing again.

Well, yes, it's Emacs, we can probably do anything we can imagine, but that's beside the point. This particular behavior is stupidly annoying for both newbies and old-timers.

Even if Emacs works internally with the concept of a "point" that is always set to a position in the visible part of a window, text editors evolved over time to adopt the concept of a "cursor" that always stays in place unless the user moves it. It's about time Emacs adopts the concept too, and sets a well-thought default behavior for it.

> Even if Emacs works internally with the concept of a "point" that is always set to a position in the visible part of a window, text editors evolved over time to adopt the concept of a "cursor" that always stays in place unless the user moves it. It's about time Emacs adopts the concept too, and sets a well-thought default behavior for it.

I'm a Vim user, not an Emacs user, which likely means my opinion isn't worth much; but I think the point I'm about to make is the same.

I use Vim because I like its user interaction paradigm. It is badly out of sync with modern text-editing paradigms, and that's fine. I would be _very_ upset if it started updating to stay relevant. If someone wants an editor that behaves more like modern editors, then they can use a modern editor; and, if they want the best of both worlds, then they can fork Vim and modify it (and there are successful projects doing exactly that). There's no need to modify core Vim to attract new users while alienating old ones.

Establishing better defaults in an application is never a bad move. Power users can still customize things to make them behave in whatever way they want, and newbies benefit from a better default setup. This doesn't mean dumbing down the UX. The goal is to provide a better ramp from newbie to power user, so that newcomers can quickly benefit from some of the cool features without having to study for a week before being able to do the most basic things.

This is how Vim does it, actually. If you keep it in insert mode, it's like a basic text editor, usually with the terminal itself taking care of basic copy-paste. Eventually, people begin dropping out to normal mode to use more and more commands.

> It's about time Emacs adopts the concept

I find this kind of thinking interesting. Like Emacs is a bold child that needs to shape up … rather than a conintiually evolving codebase developed by enthusiasts. If it doesn’t do “this thing” it’s probably because it doesn’t need to. There’s probably better ways to do this that experienced users are comfortable with. For the newbies then you only need workarounds to make them comfortable, such as that which I described.

I’m fairly positive 90% of any feature in emacs being unchanged in decades is directly attributable to backwards-compatibility than anything else. With how invasive emac scripts can be, it’s difficult to imagine anything to be changed without forcing the question: is it worth breaking userspace for this?

I don’t think the defaults are good — I suspect they’re stuck.

Why would Emacs turn down the possibility of adopting new user interaction concepts? It's not like we have to choose between "point" and "cursor", both concepts can coexist.

I find it funny to characterize Emacs as "evolving". There's been a lot of internal work, and some new features over the years, but almost all of the evolution happens on the Emacs ecosystem, not in Emacs itself. Core Emacs isn't evolving. Default Emacs is nothing more than a blank slate. And there's no clear, easy way to go from "blank slate" to "useful tool". It's either opting for one of the big config packages such as Spacemacs or Doom Emacs, or keeping Emacs as an Elisp playground (and I'd argue that an Elisp playground isn't a tool anymore, it becomes a goal in itself before it can be useful as a tool).

This is especially true of functionality that could be implemented in 15 minutes by users that so desire.

If you are thinking of a mouse oriented text editing gui where one scrolls with the scroll wheel and then clicks somewhere and starts typing from there this might make perfect sense. In fact you can of course use Emacs like that if you prefer but for keyboard oriented operation it would be absolutely odd if operations that moved the view didn't also move point and in fact other functionality depends on this. Presumably making visual point from internal point different would complexity and work and I have no idea to what end this work would be.

It would be equally weird if scrolling with a mouse wheel worked differently than scrolling with page down for example. In fact in many applications I now realize it does work differently. It's likely that I and many others are not likely to notice because when we do scroll with the scroll wheel in an editable field or document we immediately follow a series of scroll operations with a click in the appropriate location where we intend to insert text. That is to say people are unlikely to exploit the fact that visual point and point are different as a deliberate feature because its awkward. It's spacebar heating.


I would also venture to guess people are vastly more likely to scroll documents in emacs via keys compared to the scroll wheel in part because mouse scrolling emacs isn't awesome. That is a better thing to improve.

For me Emacs was only something I used when I couldn't have access to XEmacs, which was the best workaround for the lack of IDEs in 1990's UNIX.

Nowadays I just use IDEs.

I agree with basically everything in this article. Emacs needs new users, and to get them we need to reduce the barriers and user friction. In fact, increasing adoption through reducing user friction is a very well known topic in software design; this shouldn’t really be a topic for debate.

But god help you if you suggest changing Emacs to conform with modern standards. I still maintain that the worst part of Emacs is the vocal minority of evangelicals in the community.

I’ve been using Emacs as a daily driver for years, but it also took me years to adopt fully because the mental overhead of learning new terms for things I already knew drove me to ask for help from the community, and the community routinely made me not want to be any part of it.

It sucks, because most of the community is fine, but the very loud voices of a minority group of purists who have built their identities around being “Emacs people” are incredibly aggravating.

> Emacs needs new users

Why do you think so?

I've been hearing things like this for over a decade now. And compared to 10 years ago, the Emacs "ecosystem" has shown explosive growth. I can find much more useful help on Emacs on the Internet now. I can find an order more magnitude of tips/tricks than I could 10 years ago. There are many more packages easily accessible than 10 years ago.

From within, it's clear that Emacs is doing quite well in terms of its user base. The fact that its percentage market share is dropping doesn't mean it's not growing - just that other things are growing faster.

So I never understood why people imply that Emacs is somehow stagnating.

The Emacs user community is absolutely fantastic. Lisp is an amazing language to work in, and Emacs gives it to you for free. VSCode is an excellent piece of software, but you have to jump through hoops to extend it. I can extend Emacs by switching to my scratch buffer and hacking until I get what I want inside of 15 minutes in most cases. And then I drop it in an .el file and go from there.

And org-mode is absolutely fantastic when it's integrated into the editor you're writing your code in.

It’s moving, it’s just going to take a long time to get to where it needs to be. Personally I would be focused entirely on performance if I were to start making improvements.

May I ask, purely out of curiosity, where do you see does Emacs need to be? From social, cultural, technical or any other point of view that you are thinking, and why so.

At minimum it needs to be a lot faster than it is currently, and all of these comments about how you can configure it to be fast are just excuses. I’ve been using Emacs for years and my config’s performance is still something I have to hack on regularly.

Beyond that I think there’s a lot of low hanging fruit but it gets more controversial and you get a lot of really reactionary people asking why we want to attract new users, why anything needs to change at all, etc. So I’m somewhat loathe to make suggestions there, but at minimum I would try to integrate lsp-mode or Eglot as well as company (and maybe flycheck) out of the box.

I don’t think Emacs needs to be all things to all people. For one thing it has features that seem to exist mainly as misguided attempts to make it easier to use that serious users almost entirely ignore (I’m thinking mainly of Customize here). I would pare down the functionality to what the most serious Emacs users use in able to better focus on the rest, at which point it’s probably a fork, but you asked for my opinion.

> I’ve been using Emacs for years and my config’s performance is still something I have to hack on regularly.

The only performance issue I've had is startup time, and it doesn't bother me much as I have it running all the time. But certainly, if you want to keep launching new Emacs windows, you will need to optimize your config.

> but at minimum I would try to integrate lsp-mode or Eglot as well as company (and maybe flycheck) out of the box.

I can somewhat understand company-mode, as the default completion just sucks. You'll still get into an argument about which completion mode to use, as there are several good ones, and people who like a given one tend to hate the others (and then you'll get a lot of complaints from new users who have to find a way to change it...). Personally I think they should make ido and its ecosystem the default. It's good enough[1], and people who want more can modify to get helm/company/whatever. Also, ido comes with Emacs, and the others don't.

lsp-mode: IMO it's just not that "stable" and/or robust. While many love it, there are lots of complaints about people struggling with some of its quirks, and then just giving up and moving to VSCode. The other thing is that it should be trivial to turn off. As an example, I use elpy for Python programming. It's great for some projects, but for one-off Python scripts, it's incredibly annoying - so I keep elpy off by default and enable it only on some of the larger Python projects.

Flycheck: It's good, but I had performance issues. I finally dropped it for flymake. It would have totally sucked if flycheck was enabled by default when I was an Emacs newbie, and I would have erroneously ditched Emacs as being too laggy when all I would have needed was to disable flycheck.

[1] I used it for 10 years before switching to Helm. I still fall back on it sometimes.

The fundamental problem is that the large parts of the ecosystem do not use the built-in mechanisms for various reasons, which makes it hard to change the overall user experience by changing those mechanisms.

I personally use Eglot and not lsp-mode, as I found the latter extremely hard to configure. Ditto for using flymake vs flycheck. But it ultimately doesn’t matter which of these many packages gets chosen, as long as they dominate the ecosystem, provide a good experience, and are performant.

Surveys that show user distribution across vim, emacs, vscode and IDEs.

been using emacs for several years... What could be improved is speed. Too many times it doesn't see some keys combinations I hit. Screen redraw should be faster too (I spend a lot of time in front of it so that kind of "detail" is actually important). Loading big files is slow. Editing long lines is slow. Of course it doesn't happen often but when it happens it's annoying. Emacs could also propose options to better align on common behaviors (for example C-left/right arrow) doesn't behave like in other editors.

It could also be more "discoverable". There are hundreds of functions so that 100% of my needs are covered. But every now and then, when I want to find a command, I DuckDuckGo it... It'd be nicer if somehow there would be an assisted navigation in the commands (or a pointer to that assistance I've been sorely missing :-))

But I like it anyway. 'cos it's faithful, community grown, etc.

And if I had time I would contribute. But emacs is an old platform so there are many choices buried in and reaching the level of knowledge necessary to contribute is probably very high...

> been using emacs for several years... What could be improved is speed.

Same here. Long lines are especially painful. And it's quite surprising what Emacs considers a "long line". I have a file in my project with tests, where I have an array, with each element of the array on a separate line, averaging at around 125 characters per line (some of them weird Unicode characters, so not just ASCII). There are 52 lines of it. And when I scroll down the file with C-v (Page Down basically) it scrolls quickly up until I get close to this place, then I get something like 1.5 seconds delay while it's hanging there. It's ridiculous.

Another thing is how easy it is to freeze Emacs into being completely unusable when editing files over Tramp (with remote work it's the go-to solution), caused by an unreliable connection. Mostly it happens when the underlying VPN connection is dropped. When that happens, Emacs freezes with no explanation whatsoever. I can only guess what happened. C-g, Esc, nothing works, regardless whether the VPN connection is restored or not. The only solution at this point is killing this instance of Emacs. Specifically for this purpose I crafted a one-liner to kill the right instance of Emacs[1] (the one under the mouse pointer):

  kill $(xdotool getwindowpid $(xdotool getmouselocation | cut -d : -f 5))
Also, magit is painfully slow. When using it, I always wonder if Emacs is frozen again, or if it's just magit being magit. It's a shame Fork is not available for Linux.

[1]: The other instance of Emacs is used for tracking in org-mode the time I spend on different tasks. I used to do it all in a single instance, but then I kept losing that data due to Emacs freezing like that, so I started using a separate instance for the time-tracking. I really think Emacs should be a multi-process application to prevent such situations.

Regarding your long lines issue - from your description it sounds instead like an unicode issue which I also ran into a while back.

What happens is that your main programming font does not have the unicode characters, so Emacs falls back to searching all your fonts for each character it can't find, which is slow if it has to search through many different fonts.

The solution is to ensure you have symbol fonts installed - see the list of fonts here: https://github.com/rolandwalker/unicode-fonts

> some of them weird Unicode characters, so not just ASCII

This makes me suspicious that it's the font cache causing the slowdown (assuming Windows), not long lines. I saw similar symptoms a couple years ago and fixed it with (setq inhibit-compacting-font-caches t).

You could also try increasing the garbage collection threshold on the theory that the lag is a gc pause. I've used:

  (setq gc-cons-threshold (* 511 1024 1024))
  (setq gc-cons-percentage 0.5)
  (run-with-idle-timer 5 t #'garbage-collect)

Magit performance issues are definitely disappointing and I definitely wish it had a better out of the box experience. However there are plenty of resources on how to improve its performance. It's really only on big monorepos where it's frustratingly slow after mitigations. But again I agree it should have a better out of the box experience and I'm sure the maintainers agree.

Agree with the others that this is likely a Unicode bug and not a long line issue. 125 characters never causes me problems.

But yes, Emacs does have a long lines issue, sadly.

xkill ?

But I agree. Emacs should be faster.

I didn't know of xkill. Thanks!

"Buttery Smooth Emacs" contains some insight into what goes on under the surface of Emacs and is a great read: https://m.facebook.com/notes/daniel-colascione/buttery-smoot...

> Too many times it doesn't see some keys combinations I hit.

This caught my eye because I tend to think the opposite of this statement. Emacs doesn't skip a beat on text input -- unlike say VSCode which has perceivable input lag. In my experience, when Emacs gets slow it's a configuration problem, like flychecking on every keystroke, or a slow/poorly written third-party package. Raw emacs is blazing fast.

Disclaimer: I use `emacs -nw` -- no GUI toolkits.

> What could be improved is speed.

Native compilation is coming in the next version and should help quite a bit.

I'm already on the 28.0 branch, makes no visible difference (my workflow is rather basic : editing lots of code, bits of org mode, bits of WL)

Are you sure you have libgccjit installed and configure found it?

My configure's config.log says :


So, yep it has it.

i think running as a server should be made default. i imagine that alot of people are opening alot of seperate instances

I don't run Emacs as a server because it freezes occasionally and it's very painful to have a couple dozen windows in eight workspaces go down.

If I could rely on Emacs never freezing, I'd be happy to run it as a server.

I have init manage an emacs daemon but open separate emacs instances if it's doing something important, even though it practically never freezes for me. I think this works fine as long as you don't have server-start in your config.

> It could also be more "discoverable".

I definitely agree that I want to type some string and it should show a fuzzy search from all available commands and their descriptions. That would be huge timesaver for functionality I know exist, but I forgot the exact commands.

This is literally what `M-x` does. You want to do the same for functions? `C-h f`. Variables? `C-h v`. Keybindings for the current mode? `C-h ?`.

If I'm not mistaken when you install vanilla Emacs the screen even includes a tutorial and guided tour that both tell you these commands.

Yes, once you make the connection between every single keypress invoking an elisp function, and the various help combinations (variables, functions, keystrokes as you mention), I think Emacs is actually the most "discoverable" editor that I've used.

M-x completions aren't really "fuzzy" out of the box. `partial-completion` is in default `completion-styles`, yes, but then you have to do word breaks with dashes manually.

Except when the name of what you look for doesn't match your mental model (yep, I'm in the group of people who think software should adapt to human and not the other way around)

Example : I want to change the encoding of a file when I load it... Good luck figuring that out without resorting to reading the documentation.

And here I would argue that, since the documentation is included with Emacs and can be pulled up in the editor, this is still a point towards its inherent discoverability.

Again when you load emacs there's a link to the manual on its splash screen and as a guided tour. A lot of people rush to turn off this screen or suppress the menues on startup (which I get, the menu bar is pretty ugly) but they do have useful functionality for someone who doesn't know Emacs.

Discoverability is a key part of larger addons such as Spacemacs and Doom Emacs. They come configured out-of-the-box with nice completion panels for command and function search panels.

> It could also be more "discoverable". There are hundreds of functions so that 100% of my needs are covered. But every now and then, when I want to find a command, I DuckDuckGo it

Have you tried the apropos command? For me, often using helm/ido and trying to guess actually leads me to the correct command. I personally haven't even tried apropos, so I don't know how good it is.

Have you tried "native Emacs", AoT compiled with libgccjit?

The title is rather strange considering Emacs is Free Software. Forks are fine. So why not UX forks. But demanding changes to the original without going through the dev process as everyone else would need to do is rather weird. "X should do Y" seems to be the new way of treating eachother...

If you ask me, Emacs is fine as it is. In fact, I have been bitten by two changes over the time which come from the "better UI" camp. matching-paren-mode stopped to do the jumping cursor thing, which I totally rely on working with a braille display. I luckily caught this during the dev process and managed to submit a patch which adds a flag to force the "old" behaviour. And frankly, the guy who forced transient-mark mode on the world needs to hugs till he feels the pain. I am always bewildered when something I just marked suddenly vanishes just because I hit del. Move cursor a bit and DEL suddenly does something different again.

IOW, I am a long-time Emacs user, and really, stop breaking the world just because you think something needs to be "modernized". Breaking the user experience of long-term users in order to cater to newbies is rather rude to those who have invested considerable time to learn the system so they can use it as effectively as possible.

Xah Lee and friends maintains a mode called ErgoEmacs that implements most of the changes he proposed: https://github.com/ergoemacs/ergoemacs-mode

Lately there's been a lot of talk about what Emacs needs, written mostly by people who don't understand Emacs.

Emacs is more of a journey than an application. It's similar to a blacksmith forging their own tools - Emacs is the metaphorical ingot, waiting to be transformed and molded by the user.

If you're happy with what you're using then you don't need Emacs, and Emacs doesn't need to appeal to that crowd. Emacs isn't a VSCode competitor, it's something entirely different, and it's waiting for those who desire transcendence - shedding the limits imposed by other tools.

You can install and use Emacs as quickly as any other application, but to truly reap its benefit you must go deeper. I don't see the need to cater to people who clearly want something else, those tools already exist, please leave Emacs to those of us who appreciate it for what it is.

I disagree with all the reccomendations made in this article, all these changes are easy to implement, and the user is encouraged to do so - one of the main selling points of Emacs.

That doesn't mean there is not room for improvement, Emacs is still constantly improving. Additionally, I've encountered many instances where a colleague or friend introduces me to some new feature in their preferred application, the majority of the time it's a feature that's been available in Emacs for years if not decades.

I'd prefer we continue to focus on the needs of Emacs users rather than the wants of non-emacs users. Emacs will still be waiting for them when they're ready.

Seems like you completely missed the point of the article.

The article called out that none of the changes make emacs any less powerful nor do any of the changes remove any functionality. Users can still do everything they could always do with emacs. They can still take this "journey" you mention. All the changes do is let them get started quicker and jump in with at least some familiarity.

Old emacs users such as yourself can keep on using your non-standard keys and old terminology. For you, nothing would change. For new users, they'd be productive quicker and still able to take advantage of all the things that keep fans of emacs using to emacs.

I can't help but feel that you missed the point of my comment. New users should be encouraged to make those changes themselves if they feel the need to. If that's not something they're interested in, why use Emacs?

Anyone can publish a config and distribute it. For instance, the author of this article could create a 'new user friendly' config and distribute it just like doom, spacemacs, etc. If it's popular enough it will see a lot of use, but my guess is it would most likely wallow.

Making those changes default would require existing users to update their configs, not necessarily a big deal, but for what? So a new user can download Emacs, play with it for a minute, and still conclude that Emacs is a dusty relic because they don't understand the philosophy?

The whole idea of chasing new Emacs users is kind of silly, Emacs is more popular than it has ever been, and if a new user doesn't come to Emacs for what Emacs offers they were never going to stay.

Out of the box solutions already exist, Emacs is in a different category, and need not compete in that arena - especially at the expense of current users.

Appreciate the reply, cheers.

> I can't help but feel that you missed the point of my comment. New users should be encouraged to make those changes themselves if they feel the need to. If that's not something they're interested in, why use Emacs?

This whole response is the reason Emacs is rapidly approaching EOL.

You're putting the onus on new users to modify Emacs into a more beginner-friendly, standards-friendly editor? Their response would be: thanks, but I'll go try out Eclipse instead.

It's not that new users desperately want to use Emacs. It's that emacs is losing userbase at a tremendous clip because its UI and design is so ancient and crufty and because the community leaders think that's Just Fine for Them. If the emacs community wants new blood, it's they who have to implement changes to attract it.

> You're putting the onus on new users to modify Emacs into a more beginner-friendly, standards-friendly editor? Their response would be: thanks, but I'll go try out Eclipse instead.

Emacs has grown quite a bit since Eclipse's first release.

So yes, definitely let them try out Eclipse or VS Code instead. It won't hurt Emacs. See my other comment[1].

I've said it in the past, but there's a strange obsession HN folks have with comparing Emacs to VSCode or IDEs. SW development is merely one use case for Emacs. If you look at the last emacsconf, the majority of talks had nothing to do with SW development. Quite a few of the presenters, if not most, are not professional SW developers. Some of Emacs's most popular packages were created by non-programmers. Emacs will continue to grow even as fewer and fewer SW developers use Emacs for professional development.

> It's that emacs is losing userbase at a tremendous clip

Is there any evidence they are losing users? Why do people keep thinking this? As an Emacs user, I see a lot more Emacs packages being published than in the past.

[1] https://news.ycombinator.com/item?id=28342477

> New users should be encouraged to make those changes themselves if they feel the need to.

It’s not like that any more. People don’t want to write a lot of lisp configuration as soon as they pick up a new editor; there are too many good alternatives out there. For programmers working in multiple languages, VSCode is now superior because it supports LSP fantastically for many languages (source: used emacs daily for 20 years, programming for 20 years).

I agree emacs is special. And I think you and I would agree on a lot of this: I wish emacs would embrace its identity as a sharp-edged and extremely powerful tool for programmers and stop messing around trying to be friendly to new users. But that doesn’t mean having bad/antiquated defaults.We need to attract new programmers for they will be the future maintainers of emacs. (Once we move emacs development to github/gitlab and away from a bunch of old men arguing on emacs-devel).

See https://news.ycombinator.com/item?id=28185317 for my views on future emacs.

I've been using Emacs for 17 years. I want every change suggested in the article, especially 'redo'. A few additional ones:

- After pressing Alt-X, show a list of recently used commands. Allow moving between them with the up/down keys. Show a docs pane which explains what the command does, how to use it, and has an example. For new users, pre-populate the recently-used commands list with common commands. This is like the auto-complete "intellisense" function that saves me so much time when using JetBrains & VSCode.

- When opening/saving a file and typing the path, automatically show the directory contents and hi-light entries that match the path. Show recently opened files and directories in bold. Scroll the listing with PGUP/PGDN/mouse-wheel. I often use emacs to open log files which contain long unique prefixes which are error-prone to type. Allow using the mouse & arrows keys to select the file.

- Auto-save and auto-format. I love this mode when editing Rust code with CLion. It gives me something I've wanted for a long time: to write code without thinking about formatting. There's probably already some complicated way to get this to work in Emacs. Ideally, emacs would check if appropriate tools (rustfmt) are installed and make it just work automatically.

- Allow using ENTER to add newlines to a search-replace command. I can rarely remember whether it's CTRL-Q, CTRL-J, or both and frequently make mistakes.

- Allow writing Emacs commands in popular languages like Python 3 or JavaScript. Include a tutorial for each supported language. The lisp bigots will be angry about this.

- Create a public issue tracker for emacs, ideally on GitHub. This will let users help each other and participate in setting issue priorities. Include a code of conduct. Do not auto-lock old issues like Flutter Team does. Old issues are findable by search engines. Workarounds and error messages change over time. When issues are unlocked, users will add comments like "The fix now requires change X. Here's the new command that worked for me ..." Locking old issues saves the dev team some effort but destroys a lot of the utility for users.

> especially 'redo'

undo-redo is in emacs-28 now, though not the default behavior.

> Allow writing Emacs commands in popular languages like Python 3 or JavaScript.

For js see https://github.com/emacs-ng/emacs-ng

Integrating additional runtimes into the Emacs core, especially ones that also have a single main thread are likely to be a complete nightmare. There are already insane and undebugable performance issues with things that run on the main graphics event loop or on timers.

If elisp can somehow be made multi-threaded there might be a chance. However, there is SO much elisp code that assumes synchronous ordered execution that will break in subtle and unexpected ways when that restriction is lifted I expect it will take even longer than the transition to lexical scoping (and that is just in the core). I would love to be wrong though.

With respect to Python, the cpython runtime and semantics for redefinition are likely even more nighmareish because it is so easy for classes and instances to become out of sync and you wind up having to restart the whole environment just to clear out the bad state or risk creeping insanity. Also the churn in the Python ecosystem is likely far too high for Emacs to be able to maintain. So there are both technical and process mismatches. You could always run python in a separate process and use message passing though. Work to support LSP certainly paves the way for it, and elpy has fully interop with python as well, so you could use that machinery to operate on buffers in languages beyond python. So if all this is possible why isn't anyone doing it?

> After pressing Alt-X, show a list of recently used commands.

I would recommend people install/enable some of the nicer completion packages. Helm does this, for example. Personally, I wouldn't recommend helm, but I suspect all the "major" completion modes do this. Even ido/smex, I believe, does this, and it comes with Emacs (you still need to enable it, though).

Also, I suspect if you use Doom or Spacemacs this will be the default.

> When opening/saving a file and typing the path, automatically show the directory contents and hi-light entries that match the path. Show recently opened files and directories in bold. Scroll the listing with PGUP/PGDN/mouse-wheel. I often use emacs to open log files which contain long unique prefixes which are error-prone to type. Allow using the mouse & arrows keys to select the file.

I think all of this is configurable, but I'm also sure 95% of users don't want to spend too much time configuring. The default interface sucks - the problem is that there's no "improvement" that the majority likes, so the default remains a bit barebone. For example, I don't like some of your suggestions (although they are "objectively" OK). Likewise you wouldn't want it the way I have it.

> Auto-save and auto-format.

You could put a setting in your config file to enable this. Most people don't want it, though. Even in other editors.

> Allow using ENTER to add newlines to a search-replace command.

I believe this is configurable - I did something similar for a different input. But ... how do you propose someone then achieve the current effect of ENTER?

> Allow writing Emacs commands in popular languages like Python 3 or JavaScript. Include a tutorial for each supported language. The lisp bigots will be angry about this.

I would like this, but it's very challenging. I even switched to Leo Editor which was inspired by Emacs and is the closest thing you'll get to Emacs: An extremely configurable editor that you can script in Python - you can dynamically change the UI, etc. It's the equivalent of Emacs but for Python users. You may want to look into it. Unfortunately, despite being "mature", its documentation isn't the best, and it's hard to compete with all the Emacs packages out there. I gave up and decided to learn elisp - much easier than porting every Emacs feature I liked to Leo.

But Leo really has its strong points. The literate programming capabilities it is based on still haven't been replicated in Emacs - I've not found anything as good in that regard as Leo. I still occasionally fire up Leo when I find Emacs lacking.

> Create a public issue tracker for emacs

It occurred to me that anyone could create a Github project just for Emacs issues. It would be useful even if Emacs developers don't look at it. Currently people do it with StackExchange.

Interesting commentary. I do think this is a little harsh on the poor Emacs undo system.

I can't really push back on the idea that Emacs' undo system is excessively confusing, because I use Emacs and I don't understand it. I usually save text in a second buffer if I think I'll need it later.

But the solution should be to improve the UI rather than remove functionality. Consider what magit did to a similar problem in git - git is powerful with a weirdly crippled CLI. Magit adds a great ... Emacs User Interface? EUI? and all is well.

There is a probably a similar solution to the Emacs Undo problem.

Given your current situation, undo-tree-visualize will change your life.

Absolutely not. In typical Emacs fashion they took a serious complaint, fixed it and then went on to overdo it, making it unusable overkill and slow. One step redo would have been enough.

wow. is there something like this but for a whole project ?

I think that something is "git" :)

nope. what i mean is doing undo operations on a project as opposed to a buffer. lets say you have 3 buffers open and you edit buffer 1 (i), then you edit buffer 3 (ii), then you edit buffer 2 (iii), and then back to buffer 3 and you edit it some more (iv). finally you want to do project-undo from this point in buffer 3. the undo sequence then goes like this:

(iv) - (iii) - (ii) - (i)

Just add undo-tree and blow everyone's mind :)

> I usually save text in a second buffer if I think I'll need it later.

I use the kill ring for this.

Doesn't the kill ring also behave similarly. That if you move through the kill ring and stop, next time it will start from that point, rather than the latest killed text?

I always get confused if I use too much of it.

I think the default M-y does that and it's confusing. helm-show-kill-ring or counsel-yank-pop makes this much more manageable kind of like how undo-tree makes undoing simpler.

i initially hated emacs' non-CUA bindings. now my thoughts are opposite and because i spend so much time in emacs, when I need to go to CUA it's quite annoying. i agree that CUA should be made default, but with immediate option on start-up to use original emacs bindings. i think it will put off far fewer people


> Thus, every program had to be learned individually and its complete user interface memorized. It was a sign of expertise to have learned the UIs of dozens of applications, since a novice user facing a new program would find their existing knowledge of a similar application absolutely no use whatsoever.

Hello, web, looking at you. Except that no UI is stable long enough that people ever bother mastering it.

what a lot of people fail to realise is that emacs key bindings *are* consistent with other tools. Take a look at bash (or the korn shell): begin of line (C-a); end of line (C-e); kill rest of line (C-k). Emacs key bindings are the same.

Not everybody grew up using windows.

That's because GNU ReadLine uses Emacs key-bindings. It's not the other way around.

I think these key bindings go (at least) back to csh.

csh's initial release was 2 years after emacs.

C-w doesn't work the same. In bash it will delete the word before the cursor. In Emacs it will cut selection (which is always there, just sometimes invisible and then C-w does unpredictable things).

And then there's the experience of using Jupyter's terminals, where you reflexively C-w to delete the last word, but the tab closes. You then reopen the terminal, which has helpfully retained its state--including the word you just tried to delete.


I lost so many windows because of this insane default keybinding.

> Not everybody grew up using windows.

No, but almost everybody did. Very few people grew up using korn, readline, and emacs.

But I’d argue learning basic Emacs key bindings gives you the benefit of becoming better on any Linux terminal. Going through the tutorial does not take much time.

I think the author is right about the arcane terminology („meta key“, „buffer“, „window“, „frame“ etc) that should be changed and, too, configuring CUA Mode by default to help newbies a bit. I personally prefer using „control c“ and „control v“ for copy and pasting. Mind you if you like to use keyboard macros, you can’t use CUA mode copy/cut/paste bindings in them. That confused me quite a bit as beginner. However, I don’t think I ever got confused by Emacs undo system. It basically does the same thing as in other editors, just the key binding is different.

> It basically does the same thing as in other editors, just the key binding is different

I think it's the way redo works that's confusing, not necessarily undo itself. The way you have to undo, then use another command so the undos themselves become undoable, and redo by undoing the previous undos. That's not how most editors work.

note unix shells allow you to choose your keybindings! It's just as common for people to use vi keys as emacs

It's not. I don't read have numbers but my anecdata (of probably hundreds of people across several continents) is that maybe 1% of users switch to vi mode and most revert after a while.

I've been using emacs for 35+ years. It does everything I need to do. If it doesn't, it has lisp. And then it does.

I only use fundamental-mode.

Emacs, like lisp, is "clay for the mind". You can adapt it to any task easily.

I've been using programmable editors for 35+ years. They all do everything emacs does and more and are just as adaptable.

Sorry, but which programmable editor lets me read/send email, create TODOs that link both to a relevant email, and a line of code in another file, and let's me autocreate flash cards?

I bet there is a VSCode or Sublime plugin for that.

But if you prefer something more oldie, there are plenty of plugins for Ultraedit, Notepad++ and similar with scripting support.

I only use fundamental-mode.

Why? do you use emacs for programming (besides elisp)?

and emacs is already so packed.. even after rtfm 3 times thoroughly (or so I thought) I learn there's something else I didn't know about

maybe the only thing I'd like to see more center, is a blend of crdt / live-notebook in simple buffers. This could be very benefitial to newcomers too.. you can pair tutor, enjoy things in teams right inside your window

I bought the Emacs Manual from Richard Stallman and friends, so many years ago, and I still rely on it, especially with Mosh+tmux for working in remote servers.

Off topic, but I have been trying to figure out why Emacs startup got faster and editing seems snappier on an M1 MacBook. The M1 is generally faster but not enough to account for the difference. Maybe some engineers at Apple in some way optimized the Emacs that ships with macOS? The speed up has increased my use of Emacs locally on my laptop.

EDIT: I love Common Lisp, but probably it is not worth the effort to replace Emacs Lisp.

Emacs did speed-up on M1? When/How? :D

Which Emacs distribution are you using?

I just noticed that I am now running the Home Brew built for M1 install of Emacs: /opt/homebrew/bin/emacs

It is really nice to be able to have Brew installs for Intel (Rossetta) and M1 side by side (in different root directories).

Emacs doesn't appear to be preinstalled in macOS anymore (I think the ancient version they were shipping was removed with Catalina).

I'd be interested to see an exhaustive list of computer programs that are as old as emacs that people still complain about today.

Inspired in part by this article, I put together a quasi-Emacs distribution for my wife who is a writer. It turns on several of the suggestions in this article by default, such as CUA mode, etc.


Title could probably use a (2006)

or (2015)

Not sure what might still be missing, but I add the ones from XEmacs for graphical tooling integration, that might still be missing.

By the way, Gosling now rather uses IDEs.

He is THE Java guy, and java is pain without massive IDEs.

What I find here funny is that Netbeans is dead, and nobody ever mentions it on HN. And we still talk about emacs.

All programming languages are a pain without IDEs, who thinks otherwise is masochistic.

That guy did lots of stuff on his career, decades before Java was a thing, including XEmacs.

NetBeans is dead because JetBrains was a better NetBeans.

NetBeans was killed by competition with Eclipse. IDEA had nothing to do with it.

The only thing JetBrains is better is turning my laptop into a grill.

I used Aquaemacs on my work machine. It wasn’t perfect but it really did integrate well with macOS. the command key doesn’t overlap with and native emacs commands which helped.

Im using IDEs more these days but still drop text into emacs if on a remote terminal or need to use it’s macro feature.

Installing emacs plugins or extending the application always seems daunting and seems to always involve manual king editing a list config file….

Do nothing. It's awesome.

I would love Emacs to get a facelift in the UI aspect. I like what Neovim is doing for UI stuff. Maybe Remacs can head a similar direction.

Given that emacs just needs a good editor, maybe get them to integrate neovim?


To makes Emacs popular again, the core team needs to realize that their actual competitors are desktop environments, window managers, and automation tools rather than text editors and IDEs at this point. Programmers know what they want in an editor--the general populace doesn't (beyond a bare minimum of having it work like Google Docs or Microsoft Word). Emacs doesn't need to change at all, it just needs tools that go a few levels deeper in its philosophy. That is to say, first make Emacs capable of controlling non-Emacs GUIs and piloting web browsers. Second, improve automation tooling that so that individuals can make and share no-code macros for simple tasks. EXWM, an Emacs-based window manager has already taken a great first step towards accomplishing this.

Emacs is a keyboard macro editor stuck in a mouseless era where Lisp Enlightenment was still a thing. It's great, but it's niche. Most people don't actually want or need that (or to be more specific, they don't know that they need or want it).

The way to directly grow the user-base is to get the general population on board Emacs first, then evangelize for the idea underlying open software afterwards.

You do that by solving the problems that they already have more efficiently than their present solutions. Org-mode really nailed it in this department. I switched to Emacs for org-mode, but stayed for vanilla Emacs and EXWM. If Emacs were just Emacs, I'd probably be using a different editor. Without definitive hooks, Emacs is esoteric, opaque, and frightening to the general population, if they know about Emacs at all besides vim's evil rival. They just don't need Emacs in its current state.

What they do need is something that makes it trivial to automate the dumb and repetitive tasks that they have to do every day on a computer using a browser. This is no longer shell or plaintext processing for the majority of non-IT users. It's interfacing with GUIs. They need middleware to automate interfacing with kludgy enterprise software. They need middleware to speed up internet browsing.

If Emacs were a blank slate project today, fulfilling the same type of needs, I could see it being a mashup of EXWM, Selenium, and AutoIt. Its killer features would be a guarantee that the same controls (that the user selected from a common set e.g. Microsoft Word, Firefox, Vim, Emacs, etc.) worked functioned between applications. Having the ability to record mouse and keyboard macros without ever needing to see a line of code, but also providing the ability to drive using the DOM, OCR, or whatever niche smart interface is needed would be a second killer feature. These coupled with the already standard Emacs and EXWM features would attract a ton of new users that would actually have a compelling reason to learn how to use it and then later adopt to the Emacs paradigm.

EXWM is already 70% of the way for a minimum viable product for something like this. It just needs to be bundled with more mature macro tooling beyond 90s relics like xdotool and xautomation along with a distro with sane defaults. Having a single abstraction layer to control everything from userland on through web platforms would be a dream for accessibility and returning a semblance of control to users.

Why should emacs have to adopt your changes (or mine)?

Make a "Modern-Emacs" and make it what you want, make it something you and others can love. Maybe others will love it enough to contribute, maybe no one but you will ever use it. Either way is great, and you still have your ideal tool.

TL;DR * Don't change any of the naming, Emacs's naming is either better than what the article proposes, or cannot be changed everywhere it would need to be * Don't push for CUA copy/paste unless there's a plan for where to put both the C-x and C-c keymaps, and NOT on Alt (more info below) - if you have one, add a menu item to turn it and similar things on together, with help about it. * Add to the top of NEWS (C-h n) how to kill the NEWS buffer

The article's point that Emacs's use of "frame" and "window" are quirky is true, but running it on a true terminal would mean the standard use of a the word "window" wouldn't even apply. However, since few people do that now, I agree that "window" to describe the view of Emacs overall on a terminal, or in a desktop window, and "pane" for the subsections (NOT "frame") sounds reasonable. EXCEPT that this would break the name usage in a staggeringly large amount of LISP code, and thereby add cognitive dissonance when reading code, documentation, function calls and so on. So sadly, I think being resigned to being consistent instead of having different terminology for a beginner vs advanced user is a better call.

I've mapped keys for Alt, Meta, Super, and Hyper to my keyboard. Since Alt key (and AltGr) are, as far as I know, notionally for typing glyphs that aren't on the keyboard, it would be stupid to mix the Alt and Meta concepts - those need to be on different keys. All the article is doing by arguing that Alt should be hardwired in to the default emacs keymap is going down the same annoying path we did with backspace-vs-delete: Eternally confusing two different things over a keyboard layout peculiarity NOT shared by all users.

Yes, the Scratch buffer should default to text mode. Experienced users who like the current default can configure for it.

C-k and C-y are named mnemonically, so unless one wants to move copy to "Ctrl+c" and paste to "Ctrl+p" (which are both harder to read, btw, thana C-c and C-p), don't break one feature (mnemonic names) for another feature only some people prefer. Also, the kill-ring system does NOT work like copy+paste, and there are a number of complexities around X cut buffers the article author may not be aware of where something you kill/copy may not end up in the buffer the other app can yank/paste.

There also nothing wrong with "buffers" - a editor with a concept lacking in the UX many other editors is certainly allowed to apply a single consistent name to it. It's unfortunate that this use of the word is unique to software (compare "buffer zone" in normal English)... "stash" at least had a concrete meaning to non-devs ("working copy" doesn't work since the in-RAM could be the original, "draft" doesn't work because it may have been saved to disk, etc, etc). "slate" would have been an amusing choice. As with the discussion on "window"/"frame", changing "buffer" consistently would be a nightmare.

To the user complaining about copy/paste/etc not being all together, they are in contrast, bound to mnemonically reasonable keys. Also, Dvorak. Also, a huge number of PC users don't use the Ctrl+{C,V,X} anyway, and don't understand that complaint to begin with.

"Keybind" is a pretty commonly used term in PC games, and is a superset of "Keyboard shortcut" since it's understood by PC gamers to include mouse buttons and so on as well. It's notionally hard to apply "keyboard shortcut" to the act of binding a function to a mouse key, so the "keyboard shortcut" falls short of the concept and will just cause confusion. Now saying a key is "bound" to an action may be confusing, sure, and what's funny is that saying a key is "tied" to an action would probably make sense to most users. Yet those are synonyms. Go figure.

Having taught users how to use editors in Unix for years, my students only complained about one thing in Emacs - getting stuck in NEWS and not knowing how to get out. Usually this happened before they knew how to kill/switch buffers. Nothing else really bothered them, and they largely learned by using the in-editor tutorial. (those users were also taught vi, which is unquestionably harder to get started in, though vim today now points users at a tutorial)

Emacs has already been rewritten as a completely modern application in a modern programming language (JavaScript). It's called Visual Studio Code. We can now safely deprecate the original.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact