Emacs needs to be as easy to use out of the box as atom. Then, you can configure it endlessly. Just because it’s building material doesn’t mean it needs to arrive in shambles.
The fact that emacs is in such a sorry state doesn’t help anyone. It’s bad for new users that need to do so much work. It’s bad for existing users because it drives so many people away and makes the community smaller.
And maybe. The fact that emacs isn’t modern isn’t a feature. It’s an indication that it hasn’t kept up with the times, that bugs and slowness persist over decades, that there is truly a rotten broken core inside emacs that requires serious changes.
Most of the perceived lack of modernity in Emacs comes down to bad defaults, and packages which are near-universally used not being in core. Many of the bad defaults can never be changed, because it’s the policy of the developers to not disrupt the workflow of people who have been using Emacs for 30 years. And getting packages included in core is nearly impossible due to politics and the need for copyright assignment. Even packages that are included in core are generally not activated by default.
I’ve been using Emacs for 30 years now, but I’ve kept up with the times. My Emacs configuration would be as newbie friendly as VS Code if you: enabled cua-mode, re-enabled the menu bar, and told the newbie that the command palette is on M-x. Maybe enabled tab-line-mode to make buffer handling more legible, and turned on treemacs by default rather than having it on a hotkey. But it does depend on quite a few packages from both ELPA and MELPA.
I couldn’t agree more. Although, emacs has disrupted people’s configurations and changed defaults plenty of times before. There is no reason why they couldn’t ask us all to add (give-me-plain-emacs) to the start of our current configurations to maintain a bare startup, while giving everyone a much better experience. They’ve toggled modes before, removed functions, etc. Many of these required more than a 1 line change.
Many of the bad defaults can never be changed, because it’s the policy of the developers to not disrupt the workflow of people who have been using Emacs for 30 years. And getting packages included in core is nearly impossible due to politics and the need for copyright assignment. Even packages that are included in core are generally not activated by default.
Yeah, that’s what I mean by “there is truly a rotten broken core inside emacs that requires serious changes.” Politics has been strangling emacs for a long time. Every time the word “freedom” appears in an email on emacs-devel, it invariably is a discussion about how to make all of our lives just a little bit worse.
My Emacs configuration would be as newbie friendly as VS Code if you
I think you should try this and see what people do when you set this up for them. In my experience onboarding students, the unfriendliness of emacs goes much deeper than that.
Yup. I’m a 30 year emacs user, and if it came out of the box with cua-mode the first thing I’d do is m-x plain-emacs, without complaint. No reason this community should stay as hidebound as I am.
Most of the perceived lack of modernity in Emacs comes down to bad defaults, and packages which are near-universally used not being in core.
Exactly.
I have been using Emacs for 20 years, and my goal is to end up with a tiny .emacs / init.el.
Emacs is moving towards making that possible, but progress is a bit slower than what would be desirable. A quantum leap came from adopting a package manager by Emacs core. And use-package, which is sort of a de facto configuration standard.
Right now, the only two major annoyances in stock Emacs are make-backup-files and poor completion frameworks. If I start a stock Emacs in a remote machine, it litters all my directories and that should not happen by default. The second is easy to fix with vertico, marginalia, orderless, corfu et al. These are great drop-in replacements for stock completion frameworks, unlike ivy or helm, and another major milestone towards making Emacs simple and easy.
Other major annoyances come from packages. In an ideal world, I should be able to open stock Emacs, install any packages I like and use them with zero configuration. However, there is still a horrible culture of asking users to copy-paste code into .emacs to make basic functionality usable.
I used to be a heavy helm user, but I’m now using the built-in minibuffer completion, thanks to a recent (i.e. only on Emacs 29/git master) change that lets you scroll through completion candidates from the minibuffer. I still need embark and orderless, but being able to drop something as (I thought) vital as Helm is a big step.
“sorry state” and “a rotten broken core” are pretty harsh statements and it’d be nice if you were a bit more specific as to what exactly is so broken (especially at the core of Emacs).
FWIW - at least from my humble perspective Emacs has improved more in the past 5 years than in the previous 15 years, so I can definitely argue that things are not as bad as many people often portray them to be.
The fact that emacs is in such a sorry state doesn’t help anyone. It’s bad for new users that need to do so much work. It’s bad for existing users because it drives so many people away and makes the community smaller.
Agreed. We should want to build and extend communities. This post on the other hand is very much telling the people who want to do so to get off “my” lawn. Perhaps, instead, it would be better to be humble and learn from the projects that are attracting and building community.
I do need a “ascii gui” platform which I can use to build my personal workflow on top of over the years. But Emacs doesn’t feel good enough to invest significant time into:
architecturally, it’s pretty horrible with asynchrony – things routinely block GUI. I think this got better recently with the introduction of the new async API, but I don’t think it’s possible to proprely retro-fit non-blocking behavior throughout the stack
it’s pretty horrible with modularity – I want to pull other people’s code as self-contained, well-defined modules. VS Code extension marketplace is doing much better job at unleasing uncoordinated open-source creativity. I feel Emacs kits like spacemacs are popular because they solve “composition” problem unsolved in the core
it’s pretty horrible with modularity – elisp single global mutable namespace of things is good to build your tool by ourself, but is bad for building a common tool together
it’s pretty horrible with modulariy and asynchrony – poorly behaved third party code can easily block event loop (cf whith VS Code, where extensions run in a separate process, and host/plugin interface is async by construction)
elisp is a pretty horrible language – modularity, performance, lack of types, familiarity
Emacs user features make complex things possible, but they don’t make simple things easy. 90% of configuration should be editing config file with auto-completion. Emacs customize is overly complicated and unusable, so you end up writing code for 100% of config, not 10%.
Still, Emacs is probably closer to a good platform than anything else I know :-)
it’s pretty horrible with modularity – I want to pull other people’s code as self-contained, well-defined modules. VS Code extension marketplace is doing much better job at unleasing uncoordinated open-source creativity.
I think a big part of this, though, is that compared to Emacs, the extension framework in VS Code isn’t very powerful (i.e., it exposes much fewer internals), a fact that has led to bad performance for widely-used extensions which had to be solved by bringing them into core. If all you want to do is install extensions, the current Emacs package system works well enough. I do agree about the lack of namespaces; honestly, 90% of the things you mention would be fixed if Emacs were simply implemented in Common Lisp (including both modularity and asynchrony). The problem being that there is too much valuable code in Emacs Lisp.
it’s pretty horrible with modularity – elisp single global mutable namespace of things is good to build your tool by ourself, but is bad for building a common tool together
On the other hand, having all of Emacs itself be available is part of what makes it such a malleable substrate for one to build their own, customized editor out of Emacs. Having things locked down, isolated contexts, all that good “modern” stuff would certainly be nicer from a software engineering perspective, maybe make it easier to write reusable packages (although there are an awful lot of packages out there now), but would, I fear, kill what is so powerful about Emacs. The ability to introspect on just about every aspect of what the editor is doing, see the code, hook into it and change it is nearly unique and is so powerful on its own that (for good and ill) most else falls by the way-side.
I kind of wish Emacs lisp had a module system that worked like CL modules. Everything the package exports, and which is intended for other user code to interact with, you access with my-package:my-variable. But you can still get at all the internals with my-package::my-variable.
Honestly, Emacs would be strictly better were it just written in Common Lisp. Same, RMS doesn’t like it, so Emacs Lisp stayed its own separate dialect.
poorly behaved third party code can easily block event loop (cf whith VS Code, where extensions run in a separate process, and host/plugin interface is async by construction)
This works rather well in practice. There have been a couple of bugs in vsc (fixed quite quickly) over the last few years where something caused the event loop to lock up because of the main thread getting blocked, and it’s actually surprising when it happens because it’s rare.
I don’t think I am capable of designing one, but I have some thoughts.
We need some model for character-grid based GUI. Sort-of how html + dom +
event handlers allow programming the web, but simpler and with the focus on
rectangular, keyboard driven interactions. While the primary focus should be
character grid, this thing should support, eg, displaying images for the
cases you need that.
With GUI model, we should implement the core of the application, the event
loop. “nothing blocks GUI” should happen there, extension management and
isolation should happen here, window/frame management should happen here.
Given the core, we should implement some builtin components which provide the
core value, scaffold for extensions, and in general dictate the feel of the
platform. I think this should be an editor, an shell, and a
window/frame/buffer manager. And “shell” here is not the traditional
shell+emulator of an ancient physical device, but rather a shell build
holistically, from the first principles, like the thing that Arcan folks are
doing.
In parallel, there should be a common vocabulary of “widgets” for user
interaction. Things like command pallet, magit-style CLI-flavored GUI
dialogs, completion popups, configuration flow.
These all should be implemented on top of some sane software component model,
with physical separation between components. For scalable, community-driven,
long-lived system I think stability should take preference over ability to
monkey-patch internals, so we really want something like OS + processes + IPC
here, rather than a bunch of libraries in the same address space. Good news
is WebAssembly is I think building exactly that software components model
which we need here. WebAssembly components are still a WIP though.
A non-insignificant part of the component model is the delivery mechanism. I
think what Deno does might work! Otherwise, some centralized registry of
packages also a tested solution.
Another important aspect of component model is stability culture. Here I
think two-tier model makes sense – core modules are very pedantic about
their interfaces, and essentially do vscode.d.ts thing – perpetually stable,
thoroughly documented and reified-in-a-single file interface. Modules you
pull from the Internet can have whatever guarantees their authors are willing
to provide.
Hope this system doesn’t get obsoleted by the world of user-faced computing
finally collapsing into “everything is HTML” black hole.
doom emacs is very easy to use and understand out of the box. I moved to it after having my own homegrown emacs config last year, and I love it. I wish I had found it when I started using emacs.
Fully agree. I have been a long-time vim user, but found Spacemacs (too buggy) and then Doom and I haven’t looked back. space-driven commands are brilliant en extend the keyboard focus of vim to new heights (I know there is spacevim now, too late). Magit sweetens the deal – there is not git porcelain like Magit. Doom turns it all into a ready-to-use package with extremely sane defaults.
This, this 1000x this. I couldn’t get into using Emacs before I tried Doom, even though I really wanted to. Doom Emacs really makes Emacs properly usable, with all it’s straightforward configuration features.
I feel like many of the folks offering opinions here are outsiders to emacs. That is not a bad thing as we’re discussing defaults and its impacts on usage of emacs. It might be good to view these criticisms as perceptions on the barriers to entry instead of from an experiential basis, however.
I’ve used emacs for about 4 years now so I have a bit of a different perspective than the folks that have been using it for 20+ years, but I also feel like I’ve invested enough time in the community and ecosystem to have a better vantage point than that of a new or curious user.
I’ve seen a lot of progress in emacs and its ecosystem in my time using it. Emacs has gotten faster and many of the core features of popular packages have been incorporated into the main distribution (tabs, projects, advanced completion, etc). NonGNU Elpa has lowered some barriers for package developers to contribute to an official repository. I’ve seen a renewed focus on rediscovering and leveraging built-in functionality within emacs to simplify packages and benefit from the integration that provides. This is opposed to some of the more heavyweight packages that would largely re-implement built-in fuctionality. Take a look at packages like vertico, corfu, orderless, embark, consult, modus-themes, eglot, etc. The authors of these packages seem to be the next generation carrying the emacs torch forward. They have a great respect for what already exists, but are incorporating functionality that is influenced by modern UX and capabilities.
I do not feel like emacs is declining. Since I’ve used emacs, I actually feel like it has become more popular. I think Doom emacs has had a big impact on bringing in new users. I personally use vanilla emacs so I do not necessarily believe that a big configuration package like Doom or Spacemacs is required to enjoy emacs. That said, I do feel like configuration packages are very useful and I would like to see more minimal versions. If a configuration could be based on emacs 28 or greater, I believe that a very capable and polished emacs configuration could be created with minimal or no extra packages beyond those that are built-in. Maybe some config(s) could catch on so much that it would make sense to provide them as an official option sometime in the future?
The primary place where I do feel like emacs is lacking is supporting a keybinding workflow like that of most modern editors (sublime, vscode, jetbrains, etc). CUA mode is not enough. Evil and evil-collection has largely had to rebind every key to work cohesively and they drive some of the configuration packages like Doom and Spacemacs which need to provide even more polish over the packages to make for a good user experience. The fact that this is possible is a huge win for the flexibility that emacs provides, but it is a lot of effort. Many keybindings in emacs are easy to change, but some are a bit harder to change without breaking things. C-x and C-c prefix keys being one of them and then the others being the non-text editing modes like dired, magit, mu4e, etc. I’m not sure what the best way to handle those would be. Maybe some sort of semantic functionality that the keybindings could follow instead of each mode defining its own key bindings?
Emacs does not need to be a VSCode clone in a TUI.
What it does need is some ants in its pants—it needs a NeoEmacs fork with some energy behind it.
It needs something to force a rethink of defaults and such. NeoVIM did this for VIM—even users that have stayed on the original VIM project have benefited, but for the NeoVIM fork itself being able to drop legacy cruft only beneficial to 30 year old systems has enabled all sorts of new features that were being blocked. (Case in paint, I’m writing this Lobste.rs post in a full blown NeoVIM driven text area with 100% of my terminal editor environment nestled nicely in the browser.)
That does actually look promising! As a 30 year vimmer I probably won’t be using it much myself, but I will keep an eye on it. That’s the kind of project that could even improve VIM just from having the progress and diversity on the other side of the fence. I’ll take NeoVIM’s Lua over emacs-ng’s Javascript personally, but I think both are a win. The progress in a canvas and just being able to have more than one front end is cool too.
I do think that Emacs as the editor as it exists in the world is dying. Which is a shame, because I am a heavy Emacs user and won’t switch to anything else – everything I’ve tried has foundered on some piece of functionality or other that Emacs provides, or just fights against my inbuilt muscle memory
Emacs is, though, the only existing system that shows what a unified, user-owned computer would look like. It’s not good at being a fully transparent, plastic, user designed system; but it is better than anything else.
I have never used emacs or been interested in using emacs. (kwrite forever!) But I want to weigh in on the “but vim” comment - vim.tiny comes preinstalled on Ubuntu. I’d be willing to wager that 95% of vim users never use 1. any mode other than insert, 2. any feature more advanced than search. That’s not a relevant comparison product for emacs.
ship by default “cool” themes like Solarized (it seems it’s very important to have some dark mode these days)
Yes, this is superficial and better left up to the user.
make Emacs more mouse-friendly (e.g. right clicking would open some context menus, there would be more tooltips on mouse hover and so on)
have a fancy configuration wizard to help with the initial setup of Emacs
These are, however, really powerful things that would greatly help both new and old users!
The mouse support in Emacs is already great, but many experienced users turn it off (menu-bar and tool-bar) to reduce clutter in the UI; adding that back in with context menus provides a way to help both experienced and novice users.
And many new users go straight to unnecessary heavy Emacs configuration frameworks, even if just a few basic customizations are all they want. This then makes life difficult for other experienced users who want to help them, but don’t know how to navigate the heavy-weight framework. Encouraging more use of customize and built-in Emacs features helps everyone.
Yes, this is superficial and better left up to the user.
Particularly when the author himself is responsible for an absolutely terrible emacs port of Solarized, which is best avoided at all costs. The last thing Emacs needs is new users asking why turning on the solarized theme inflicted a bunch of randomly different font sizes on their poor code when they’re expecting the kind of solarized experience they’d get from any other editor’s solarized port, instead.
Well, I’m sorry you feel like this about Solarized and you’re always free to voice your concerns on the issue tracker as well. ;-)
You are missing my point, though - for how many people exactly will bundling a theme like Solarized (or another other popular theme, that has been ported to your standards to Emacs) and making it the default be deciding factor to use or not use Emacs? :-) After all most themes are trivial to install even today. There are 20+ themes in the default Emacs repos today + a few themes that are bundled with Emacs.
To be clear - I don’t mind making Emacs more approachable to newcomers at all. I’m just skeptical this is going to make a difference for the broader adoption of Emacs. Also I view user-friendliness and ease of use as being orthogonal to being “modern” (e.g. Emacs can be “dated” and user-friendly at the same time), that’s why in general I don’t like it when those two concepts get conflated.
I think these discussions are bike shedding because they focus on technical merits and capabilities while measuring the state of emacs by popularity. Popularity is only residual coupled with the technical merits of a product these days. Marketing, trends, aesthetics and network effect play a much bigger role nowadays.
Is being a very popular editor a goal of the project? I think its 40+ years of history scream a loud no. Emacs is from a time when people use what they could find. An editor packed with functionality like emacs, would mean an almost obscene productivity boost and everyone would absolutely embrace its ways, whatever they were. Nowadays there are countless options, people can afford to pick based on tiny criteria. To the point of “I don’t need to spend an hour configuring it”.
Arguably, for those who like emacs the way it is, it is the best editor. If you remove popularity out of the equation, then for those people there is absolutely no reason to change.
A point that gets ignored all the time is that it is an open source project. Anyone is free to fork it. I feel like criticism of it being old fashioned and having a strict mentality is misguided. What’s stopping you from forking it? If the answer is in the lines of requiring coordinated effort of a large amount of people, then we are getting to the important part of this discussion. Interacting with many engineers at work, I would say that things like doom emacs or spacemacs are getting even more popular among non-hackers than emacs. Many people that use these are not even aware of what emacs is.
VSCode is being mentioned repeatedly as the one eating emacs lunch. While it appeared when emacs was already deep in its decline. I think this assessment is actually accurate. The reason being that VSCode captures much of the emacs mindset.
I tried VSCode when it was launched and it was virtually unknown at the time. Atom was already well established. I didn’t became a user at once because gedit2 was still an active project and was serving me well. But I liked what I saw:
MRU file switching. This was the standard until mid 2000s then editors started abondining this for some unknown reason
Split view.
Built in terminal set on the project folder by default
quick open. This was one the reasons why I loved gedit as it was one of the first editors offering this feature
proper open folder functionality rather than glitchy project files non sense.
markdown preview
snappy and quick to launch, unlike atom. Start up time has since degraded though
just the right amount of git integration. I find git GUIs intuitive compared to the CLI, but showing current changes in a working copy in a clear way, is useful
So in essence, yes. It has a well put together set of default features. But, what I think aesthetics, network effect and marketing is what brings the masses to it. It’s threat to emacs is more in the lines of it fitting the needs of the typical emacs user, rather than attracting more new blood than emacs.
If you goal is to view files and system then your shell is even cleaner so you probably don’t even need Emacs. That isn’t really the goal of the majority of people using Emacs though.
Of course when I say view files I also mean edit them. Between running my shell in emacs and using dired, it’s a lot cleaner than shell cli. For me, anyway.
I’ve been using (doom) emacs for just about a year now. Org mode got me to switch from vim. I just recently wrote my first custom key binding to support getting lsp-mode for golang working. As long as it’s on par with vim, I’ll continue to learn how to tweak it from the outside in.
I’ve used Emacs for ~20 years (so I’m another grumpy old man in
this regard) and while I agree on some points in the list, I think
that we should just let Emacs be the ancient dinosaur it is. No
matter how much we change the defaults, it’s still strange
defaults all the way down.
I used to miss tabs in Emacs - now I miss buffer management in all
other editors I use.
I used to think Elisp should be replaced - but that would make
large parts of the ecosystem obselete, removing a lot of the great
parts
et c
But column-number-mode should be enabled by default. I don’t care
what happens to the modeline but please give me my
column-number-mode.
And I also wish mu4e could be included in Emacs core, mu4e is
great!
Yeah, I’ve been using Emacs on and off for some 25 years and every time I launch Visual Code almost everything feels better. Emacs still has a superior basis and better underlying philosophy which makes me drift back to it, but neither of those would be (necessarily) harmed by a easier-to-use Emacs.
I have tried to learn Emacs repeatedly, going back nearly years now, ever since I read In The Beginning Was The Command Line. It’s always defeated me.
Yes, I feel it needs modernisation. I’ve tried to discuss how and why with some Emacs aficionadi and evangelists, but they rebuff me. I emailed @bbatsov about this, and he pointed me at this discussion.
So I thought: why not comment here?
First: why I can’t get into it.
I’m old. I’ve been doing computers for over 40 years now, working in the industry over 30. This doesn’t mean I can’t learn new stuff. I can and I do. It’s a professional skill.
What it really means in context is that I’ve learned so many different text editors that I’ve lost count. I started on PET BASIC, then a ZX Spectrum, then almost every 1980s micro. In my work, I learned xNix on SCO Xenix in 1988, and therefore had to learn Vi. (I hated it.) At the same time, I learned DOS. And therefore I had to learn Edlin, because there was no other editor as standard in DOS at the time. It reminded me of DEC VMS EDT but many times worse.
I got an Amstrad PCW at home, and learned CP/M and RPED and LocoScript.
At work, I also learned WordStar and DisplayWrite and MultiMate, and WordPerfect, and umpteen more. Mac System 6, TeachText, SimpleText, WriteNow, MS Word for DOS and Mac and then Windows 2.
I bought an Acorn Archimedes with RISC OS: a powerful 32-bit RISC home computer with a totally proprietary OS (although it’s still around and it’s FOSS now) descended from a line of microcomputers as old as CP/M, meaning no influence from CP/M or the American mainstream of computers. Very weird command lines, very weird filesystems, very weird editors, but all integrated and very powerful and capable. (It has a very strange two-cursor editing system: one insertion/text entry cursor, and another copy-from editor, and possibly a mouse pointer as well making three).
I killed it by botching a hardware expansion installation, so I bought a 2nd hand PC laptop and put OS/2 2.0 on it. So I had to move to the same tools I used at work on DOS and Windows.
I had to learn to work dozens of different editors with dozens of different UIs because that’s how 1980s computing was. There were no UI standards yet.
But then, everything changed.
What happened in the early 1990s was that the wave of old DOS apps, with strange, idiosyncratic UIs – sometimes inherited from CP/M versions, been ported to DOS (such as WordStar) – ran up against the new wave of standardisation imposed by (classic) MacOS and early Windows (meaning 2 and 3 here, long before Win95).
The GUI OSes that were catching on had standardised UIs.
This meant: standard layouts for menus, contents of menus, for dialog boxes, for keystrokes as well as mouse actions. UIs got forcibly standardised, mostly around IBM CUA – I wrote much of that article – and late-1980s/early-1990s DOS apps mostly had to conform, or die.
And conform they did. Even then-quite-modern apps like WordPerfect gained menu bars and changed their weird keystrokes to conform. If their own weird UIs conflicted, then the standards took over. WordPerfect had a very powerful, efficient, UI driven by function keys. But it wasn’t compatible with the new standards. It used F3 for help and Escape to repeat a character, command or macro. The new standards said F1 must be help and Esc must be cancel. So WordPerfect complied.
And until the company stumbled, porting to OS/2 and ignoring Windows until it was too late, it worked. WordPerfect remained the dominant industry-standard, even as its UI got modernised. Users adapted.
Any you know what? It was great. It was such a relief. I could forget all those weird arcane UIs, because suddenly, DOS or Windows or Mac or OS/2 or whatever, it didn’t matter, Ctrl+O opened a file. Ctrl+S saved it. Ctrl+P printed it. Ctrl+F started a Find. Ctrl+Z/X/C/V always did Undo, Cut, Copy, Paste. Esc closed a dialog box or a prompt or whatever. F1 gave you help.
Today, all modern editors, console or GUI, whatever the GUI, have this UI.
Kate, KWrite, Geany, Leafpad, Mousepad, Notepad, Notepad++, Gedit before GNOME 3 and CSD. They all have the same core UI.
Like it or not, for more than three decades, there’s been a standard language for UIs and so on. “Files”, “windows”, the “clipboard”, “cut”, “copy”, “paste”. Standard menus, in standard positions, with standard commands on them, in a standard order, accessed with standard keystrokes.
And 99% of this applies to Atom, and Sublime Text, and VSCode, and so on. I don’t like any of ‘em much. Atom is the least bad and it’s a bloated mess IMHO. But it’s an Electron app, and they all are.
Eight Megs And Constantly Swapping my a$$. Is that all?
So why am I talking about this?
Because the world of tools like Emacs never underwent this modernisation.
Vi ignores this. Its fans love its power and efficiency and are willing to learn its weird UI.
But Vi (and Vim and Elvis etc.) aren’t very customisable. You can’t easily change their UI. They are what they are.
Emacs ignores this, for the same reasons. The manual and tutorial talk about “buffers” and “scratchpads” and “Meta keys” and dozens of things that no computer made in 40 years has: a whole different language before the Mac and DOS and Windows transformed the world of computing.
But Emacs is customisable. That is a big part of its appeal. It’s infinitely customisable. It’s a whole framework for building apps. It reads mail, and news, and has web browsers, and everything.
What I propose is a wholescale rework of the UI. cua-mode is not enough.
The good news: most of it has been done: it’s called ErgoEmacs. It’s in Melpa, but if you’re not an Emacser already, that’s very hard to install and harder still to set for your regional keyboard layout.
What I propose is twofold.
[1]
Someone starts with another Emacs distro, like Doom or Spacemacs or something, or maybe even a fork, like emacs-ng or commercial-emacs… but aimed at making Emacs look like a standard text editor with a default file type of plain text, not any programming language.
That it defaults to plain text. Not to Lisp, not to any language mode, unless a file with a recognised extension is opened. Plain text in the regional default of that user account. No autocomplete, no highlighting, nothing. Text before anything. Fragments of Lisp being offered and then disappearing as a newbie types are weird and confusing.
On first run, if no config file is found, then by default, it opens in ErgoEmacs’ CUA UI, be that on the console or in the GUI. Standard menus, referring to Ctrl and Alt/Opt and Windows/Super like every keyboard on every computer made since 1985 has. No “meta”. Standard meanings of “windows” and so on.
Same for the manual, tutorial, etc.
I don’t care about themes, dark mode, font rendering, any of that. Anything of that you want, go mad.
But the standard CUA-compliant UI, on by default, no configuration required.
[2]
That all of this vanishes if it’s installed for an existing Emacs user.
If Emacs launches and finds an existing config file, all this stuff is ignored. Go back to the standards. Nothing that in any way inconveniences existing users. That’s really important.
I’m not a big Emacs user. I’m not saying that I don’t like it. Just that I don’t use it that much. I keep it there on my task bar as one of the various editors I use for various jobs. One thing though that would make it increase my personal usage of it though, is speed. But I know that interpreting Elisp is not necessarily quick and writing a new interpreter while making sure to maintain compatibility with the tens of thousands of Elisp extension already in the wild would be highly improbable.
Hey, you might as well look at Lem: https://github.com/lem-project/lem/ it’s built in CL and it is usable right now, for CL and other languages out of the box. It works on the terminal and it has experimental Electron and OpenGL UIs.
I wouldn’t mind deleting a few items from my .emacs because they were standard out of the box.
eg. helm and projectile should be standard (plus a bunch of their addons)
Admittedly I don’t expect everyone to agree on which navigation and narrowing framework, but it would be nice if some of the best were default and the others selectable from the menu instead of install from melpa and configure.
I suspect there are other really good packages I don’t use that I should be using, but they are not part of the standard install and I haven’t understood how good they are.
Building blocks are fine when you got time to build. But nowadays not many do. We have stuff to do, we don’t have time to figure out configurations, unfortunately.
If I would use emacs, i would just use doom-emacs and call it a day.
I have my own neovim config however, because all the configs i could find were full of stuff I didnt need..
If you liked doom-emacs, you might like doom-nvim. Its philosophy is that you can use only what you need from it.
Also found kickstart.nvim and neovim-from-scratch useful for writing my own neovim config (well, for “modernising” my previous Vim8 config).
Everyone.
Emacs needs to be as easy to use out of the box as atom. Then, you can configure it endlessly. Just because it’s building material doesn’t mean it needs to arrive in shambles.
The fact that emacs is in such a sorry state doesn’t help anyone. It’s bad for new users that need to do so much work. It’s bad for existing users because it drives so many people away and makes the community smaller.
And maybe. The fact that emacs isn’t modern isn’t a feature. It’s an indication that it hasn’t kept up with the times, that bugs and slowness persist over decades, that there is truly a rotten broken core inside emacs that requires serious changes.
Heavy emacs user for almost 20 years.
Most of the perceived lack of modernity in Emacs comes down to bad defaults, and packages which are near-universally used not being in core. Many of the bad defaults can never be changed, because it’s the policy of the developers to not disrupt the workflow of people who have been using Emacs for 30 years. And getting packages included in core is nearly impossible due to politics and the need for copyright assignment. Even packages that are included in core are generally not activated by default.
I’ve been using Emacs for 30 years now, but I’ve kept up with the times. My Emacs configuration would be as newbie friendly as VS Code if you: enabled cua-mode, re-enabled the menu bar, and told the newbie that the command palette is on M-x. Maybe enabled tab-line-mode to make buffer handling more legible, and turned on treemacs by default rather than having it on a hotkey. But it does depend on quite a few packages from both ELPA and MELPA.
I couldn’t agree more. Although, emacs has disrupted people’s configurations and changed defaults plenty of times before. There is no reason why they couldn’t ask us all to add (give-me-plain-emacs) to the start of our current configurations to maintain a bare startup, while giving everyone a much better experience. They’ve toggled modes before, removed functions, etc. Many of these required more than a 1 line change.
Yeah, that’s what I mean by “there is truly a rotten broken core inside emacs that requires serious changes.” Politics has been strangling emacs for a long time. Every time the word “freedom” appears in an email on emacs-devel, it invariably is a discussion about how to make all of our lives just a little bit worse.
I think you should try this and see what people do when you set this up for them. In my experience onboarding students, the unfriendliness of emacs goes much deeper than that.
Yup. I’m a 30 year emacs user, and if it came out of the box with cua-mode the first thing I’d do is m-x plain-emacs, without complaint. No reason this community should stay as hidebound as I am.
Exactly.
I have been using Emacs for 20 years, and my goal is to end up with a tiny .emacs / init.el.
Emacs is moving towards making that possible, but progress is a bit slower than what would be desirable. A quantum leap came from adopting a package manager by Emacs core. And
use-package, which is sort of a de facto configuration standard.Right now, the only two major annoyances in stock Emacs are
make-backup-filesand poor completion frameworks. If I start a stock Emacs in a remote machine, it litters all my directories and that should not happen by default. The second is easy to fix with vertico, marginalia, orderless, corfu et al. These are great drop-in replacements for stock completion frameworks, unlike ivy or helm, and another major milestone towards making Emacs simple and easy.Other major annoyances come from packages. In an ideal world, I should be able to open stock Emacs, install any packages I like and use them with zero configuration. However, there is still a horrible culture of asking users to copy-paste code into .emacs to make basic functionality usable.
I used to be a heavy helm user, but I’m now using the built-in minibuffer completion, thanks to a recent (i.e. only on Emacs 29/git master) change that lets you scroll through completion candidates from the minibuffer. I still need embark and orderless, but being able to drop something as (I thought) vital as Helm is a big step.
“sorry state” and “a rotten broken core” are pretty harsh statements and it’d be nice if you were a bit more specific as to what exactly is so broken (especially at the core of Emacs).
FWIW - at least from my humble perspective Emacs has improved more in the past 5 years than in the previous 15 years, so I can definitely argue that things are not as bad as many people often portray them to be.
Agreed. We should want to build and extend communities. This post on the other hand is very much telling the people who want to do so to get off “my” lawn. Perhaps, instead, it would be better to be humble and learn from the projects that are attracting and building community.
/me raises hand.
I do need a “ascii gui” platform which I can use to build my personal workflow on top of over the years. But Emacs doesn’t feel good enough to invest significant time into:
Still, Emacs is probably closer to a good platform than anything else I know :-)
I think a big part of this, though, is that compared to Emacs, the extension framework in VS Code isn’t very powerful (i.e., it exposes much fewer internals), a fact that has led to bad performance for widely-used extensions which had to be solved by bringing them into core. If all you want to do is install extensions, the current Emacs package system works well enough. I do agree about the lack of namespaces; honestly, 90% of the things you mention would be fixed if Emacs were simply implemented in Common Lisp (including both modularity and asynchrony). The problem being that there is too much valuable code in Emacs Lisp.
On the other hand, having all of Emacs itself be available is part of what makes it such a malleable substrate for one to build their own, customized editor out of Emacs. Having things locked down, isolated contexts, all that good “modern” stuff would certainly be nicer from a software engineering perspective, maybe make it easier to write reusable packages (although there are an awful lot of packages out there now), but would, I fear, kill what is so powerful about Emacs. The ability to introspect on just about every aspect of what the editor is doing, see the code, hook into it and change it is nearly unique and is so powerful on its own that (for good and ill) most else falls by the way-side.
I kind of wish Emacs lisp had a module system that worked like CL modules. Everything the package exports, and which is intended for other user code to interact with, you access with my-package:my-variable. But you can still get at all the internals with my-package::my-variable.
Honestly, Emacs would be strictly better were it just written in Common Lisp. Same, RMS doesn’t like it, so Emacs Lisp stayed its own separate dialect.
But hey, at least it’s a Lisp!
This works rather well in practice. There have been a couple of bugs in vsc (fixed quite quickly) over the last few years where something caused the event loop to lock up because of the main thread getting blocked, and it’s actually surprising when it happens because it’s rare.
What would the ideal such platform look like?
It’s hard!
I don’t think I am capable of designing one, but I have some thoughts.
We need some model for character-grid based GUI. Sort-of how html + dom + event handlers allow programming the web, but simpler and with the focus on rectangular, keyboard driven interactions. While the primary focus should be character grid, this thing should support, eg, displaying images for the cases you need that.
With GUI model, we should implement the core of the application, the event loop. “nothing blocks GUI” should happen there, extension management and isolation should happen here, window/frame management should happen here.
Given the core, we should implement some builtin components which provide the core value, scaffold for extensions, and in general dictate the feel of the platform. I think this should be an editor, an shell, and a window/frame/buffer manager. And “shell” here is not the traditional shell+emulator of an ancient physical device, but rather a shell build holistically, from the first principles, like the thing that Arcan folks are doing.
In parallel, there should be a common vocabulary of “widgets” for user interaction. Things like command pallet, magit-style CLI-flavored GUI dialogs, completion popups, configuration flow.
These all should be implemented on top of some sane software component model, with physical separation between components. For scalable, community-driven, long-lived system I think stability should take preference over ability to monkey-patch internals, so we really want something like OS + processes + IPC here, rather than a bunch of libraries in the same address space. Good news is WebAssembly is I think building exactly that software components model which we need here. WebAssembly components are still a WIP though.
A non-insignificant part of the component model is the delivery mechanism. I think what Deno does might work! Otherwise, some centralized registry of packages also a tested solution.
Another important aspect of component model is stability culture. Here I think two-tier model makes sense – core modules are very pedantic about their interfaces, and essentially do vscode.d.ts thing – perpetually stable, thoroughly documented and reified-in-a-single file interface. Modules you pull from the Internet can have whatever guarantees their authors are willing to provide.
Hope this system doesn’t get obsoleted by the world of user-faced computing finally collapsing into “everything is HTML” black hole.
doom emacs is very easy to use and understand out of the box. I moved to it after having my own homegrown emacs config last year, and I love it. I wish I had found it when I started using emacs.
Fully agree. I have been a long-time vim user, but found Spacemacs (too buggy) and then Doom and I haven’t looked back. space-driven commands are brilliant en extend the keyboard focus of vim to new heights (I know there is spacevim now, too late). Magit sweetens the deal – there is not git porcelain like Magit. Doom turns it all into a ready-to-use package with extremely sane defaults.
This, this 1000x this. I couldn’t get into using Emacs before I tried Doom, even though I really wanted to. Doom Emacs really makes Emacs properly usable, with all it’s straightforward configuration features.
I feel like many of the folks offering opinions here are outsiders to emacs. That is not a bad thing as we’re discussing defaults and its impacts on usage of emacs. It might be good to view these criticisms as perceptions on the barriers to entry instead of from an experiential basis, however.
I’ve used emacs for about 4 years now so I have a bit of a different perspective than the folks that have been using it for 20+ years, but I also feel like I’ve invested enough time in the community and ecosystem to have a better vantage point than that of a new or curious user.
I’ve seen a lot of progress in emacs and its ecosystem in my time using it. Emacs has gotten faster and many of the core features of popular packages have been incorporated into the main distribution (tabs, projects, advanced completion, etc). NonGNU Elpa has lowered some barriers for package developers to contribute to an official repository. I’ve seen a renewed focus on rediscovering and leveraging built-in functionality within emacs to simplify packages and benefit from the integration that provides. This is opposed to some of the more heavyweight packages that would largely re-implement built-in fuctionality. Take a look at packages like vertico, corfu, orderless, embark, consult, modus-themes, eglot, etc. The authors of these packages seem to be the next generation carrying the emacs torch forward. They have a great respect for what already exists, but are incorporating functionality that is influenced by modern UX and capabilities.
I do not feel like emacs is declining. Since I’ve used emacs, I actually feel like it has become more popular. I think Doom emacs has had a big impact on bringing in new users. I personally use vanilla emacs so I do not necessarily believe that a big configuration package like Doom or Spacemacs is required to enjoy emacs. That said, I do feel like configuration packages are very useful and I would like to see more minimal versions. If a configuration could be based on emacs 28 or greater, I believe that a very capable and polished emacs configuration could be created with minimal or no extra packages beyond those that are built-in. Maybe some config(s) could catch on so much that it would make sense to provide them as an official option sometime in the future?
The primary place where I do feel like emacs is lacking is supporting a keybinding workflow like that of most modern editors (sublime, vscode, jetbrains, etc). CUA mode is not enough. Evil and evil-collection has largely had to rebind every key to work cohesively and they drive some of the configuration packages like Doom and Spacemacs which need to provide even more polish over the packages to make for a good user experience. The fact that this is possible is a huge win for the flexibility that emacs provides, but it is a lot of effort. Many keybindings in emacs are easy to change, but some are a bit harder to change without breaking things.
C-xandC-cprefix keys being one of them and then the others being the non-text editing modes like dired, magit, mu4e, etc. I’m not sure what the best way to handle those would be. Maybe some sort of semantic functionality that the keybindings could follow instead of each mode defining its own key bindings?Emacs does not need to be a VSCode clone in a TUI.
What it does need is some ants in its pants—it needs a NeoEmacs fork with some energy behind it.
It needs something to force a rethink of defaults and such. NeoVIM did this for VIM—even users that have stayed on the original VIM project have benefited, but for the NeoVIM fork itself being able to drop legacy cruft only beneficial to 30 year old systems has enabled all sorts of new features that were being blocked. (Case in paint, I’m writing this Lobste.rs post in a full blown NeoVIM driven text area with 100% of my terminal editor environment nestled nicely in the browser.)
This is pretty exciting - https://emacs-ng.github.io/emacs-ng/
How, if at all, does this compare to:
https://github.com/commercial-emacs/commercial-emacs
…?
(Not an Emacs user, for reasons I can give elsewhere.)
That does actually look promising! As a 30 year vimmer I probably won’t be using it much myself, but I will keep an eye on it. That’s the kind of project that could even improve VIM just from having the progress and diversity on the other side of the fence. I’ll take NeoVIM’s Lua over emacs-ng’s Javascript personally, but I think both are a win. The progress in a canvas and just being able to have more than one front end is cool too.
I do think that Emacs as the editor as it exists in the world is dying. Which is a shame, because I am a heavy Emacs user and won’t switch to anything else – everything I’ve tried has foundered on some piece of functionality or other that Emacs provides, or just fights against my inbuilt muscle memory
Emacs is, though, the only existing system that shows what a unified, user-owned computer would look like. It’s not good at being a fully transparent, plastic, user designed system; but it is better than anything else.
I have never used emacs or been interested in using emacs. (kwrite forever!) But I want to weigh in on the “but vim” comment - vim.tiny comes preinstalled on Ubuntu. I’d be willing to wager that 95% of vim users never use 1. any mode other than insert, 2. any feature more advanced than search. That’s not a relevant comparison product for emacs.
Vim is not the other Emacs, Vim is the new Ed.
This list is somewhat dishonest. It starts with:
Yes, this is superficial and better left up to the user.
These are, however, really powerful things that would greatly help both new and old users!
The mouse support in Emacs is already great, but many experienced users turn it off (menu-bar and tool-bar) to reduce clutter in the UI; adding that back in with context menus provides a way to help both experienced and novice users.
And many new users go straight to unnecessary heavy Emacs configuration frameworks, even if just a few basic customizations are all they want. This then makes life difficult for other experienced users who want to help them, but don’t know how to navigate the heavy-weight framework. Encouraging more use of customize and built-in Emacs features helps everyone.
Particularly when the author himself is responsible for an absolutely terrible emacs port of Solarized, which is best avoided at all costs. The last thing Emacs needs is new users asking why turning on the solarized theme inflicted a bunch of randomly different font sizes on their poor code when they’re expecting the kind of solarized experience they’d get from any other editor’s solarized port, instead.
Well, I’m sorry you feel like this about Solarized and you’re always free to voice your concerns on the issue tracker as well. ;-)
You are missing my point, though - for how many people exactly will bundling a theme like Solarized (or another other popular theme, that has been ported to your standards to Emacs) and making it the default be deciding factor to use or not use Emacs? :-) After all most themes are trivial to install even today. There are 20+ themes in the default Emacs repos today + a few themes that are bundled with Emacs.
To be clear - I don’t mind making Emacs more approachable to newcomers at all. I’m just skeptical this is going to make a difference for the broader adoption of Emacs. Also I view user-friendliness and ease of use as being orthogonal to being “modern” (e.g. Emacs can be “dated” and user-friendly at the same time), that’s why in general I don’t like it when those two concepts get conflated.
I think these discussions are bike shedding because they focus on technical merits and capabilities while measuring the state of emacs by popularity. Popularity is only residual coupled with the technical merits of a product these days. Marketing, trends, aesthetics and network effect play a much bigger role nowadays.
Is being a very popular editor a goal of the project? I think its 40+ years of history scream a loud no. Emacs is from a time when people use what they could find. An editor packed with functionality like emacs, would mean an almost obscene productivity boost and everyone would absolutely embrace its ways, whatever they were. Nowadays there are countless options, people can afford to pick based on tiny criteria. To the point of “I don’t need to spend an hour configuring it”.
Arguably, for those who like emacs the way it is, it is the best editor. If you remove popularity out of the equation, then for those people there is absolutely no reason to change.
A point that gets ignored all the time is that it is an open source project. Anyone is free to fork it. I feel like criticism of it being old fashioned and having a strict mentality is misguided. What’s stopping you from forking it? If the answer is in the lines of requiring coordinated effort of a large amount of people, then we are getting to the important part of this discussion. Interacting with many engineers at work, I would say that things like doom emacs or spacemacs are getting even more popular among non-hackers than emacs. Many people that use these are not even aware of what emacs is.
VSCode is being mentioned repeatedly as the one eating emacs lunch. While it appeared when emacs was already deep in its decline. I think this assessment is actually accurate. The reason being that VSCode captures much of the emacs mindset. I tried VSCode when it was launched and it was virtually unknown at the time. Atom was already well established. I didn’t became a user at once because gedit2 was still an active project and was serving me well. But I liked what I saw:
So in essence, yes. It has a well put together set of default features. But, what I think aesthetics, network effect and marketing is what brings the masses to it. It’s threat to emacs is more in the lines of it fitting the needs of the typical emacs user, rather than attracting more new blood than emacs.
Emacs is a very clean pane of glass through which to view your files and system. Adding curtains and a valance isn’t going to make it any cleaner.
If you goal is to view files and system then your shell is even cleaner so you probably don’t even need Emacs. That isn’t really the goal of the majority of people using Emacs though.
Of course when I say view files I also mean edit them. Between running my shell in emacs and using dired, it’s a lot cleaner than shell cli. For me, anyway.
If you stick to the same hardware and OS release forever then you probably don’t need a modern Emacs. Others, like me, do upgrade from time to time.
To give you an example: I purchased a 4k monitor and set up fractional scaling in Gnome with Wayland. It turns out Emacs 27 is blurry. My options:
I personally went with option (4).
I’ve been using (doom) emacs for just about a year now. Org mode got me to switch from vim. I just recently wrote my first custom key binding to support getting lsp-mode for golang working. As long as it’s on par with vim, I’ll continue to learn how to tweak it from the outside in.
I’ve used Emacs for ~20 years (so I’m another grumpy old man in this regard) and while I agree on some points in the list, I think that we should just let Emacs be the ancient dinosaur it is. No matter how much we change the defaults, it’s still strange defaults all the way down.
I used to miss tabs in Emacs - now I miss buffer management in all other editors I use. I used to think Elisp should be replaced - but that would make large parts of the ecosystem obselete, removing a lot of the great parts et c
But column-number-mode should be enabled by default. I don’t care what happens to the modeline but please give me my column-number-mode.
And I also wish mu4e could be included in Emacs core, mu4e is great!
Yeah, I’ve been using Emacs on and off for some 25 years and every time I launch Visual Code almost everything feels better. Emacs still has a superior basis and better underlying philosophy which makes me drift back to it, but neither of those would be (necessarily) harmed by a easier-to-use Emacs.
Interesting piece.
I have tried to learn Emacs repeatedly, going back nearly years now, ever since I read In The Beginning Was The Command Line. It’s always defeated me.
Yes, I feel it needs modernisation. I’ve tried to discuss how and why with some Emacs aficionadi and evangelists, but they rebuff me. I emailed @bbatsov about this, and he pointed me at this discussion.
So I thought: why not comment here?
First: why I can’t get into it.
I’m old. I’ve been doing computers for over 40 years now, working in the industry over 30. This doesn’t mean I can’t learn new stuff. I can and I do. It’s a professional skill.
What it really means in context is that I’ve learned so many different text editors that I’ve lost count. I started on PET BASIC, then a ZX Spectrum, then almost every 1980s micro. In my work, I learned xNix on SCO Xenix in 1988, and therefore had to learn Vi. (I hated it.) At the same time, I learned DOS. And therefore I had to learn Edlin, because there was no other editor as standard in DOS at the time. It reminded me of DEC VMS EDT but many times worse.
I got an Amstrad PCW at home, and learned CP/M and RPED and LocoScript.
At work, I also learned WordStar and DisplayWrite and MultiMate, and WordPerfect, and umpteen more. Mac System 6, TeachText, SimpleText, WriteNow, MS Word for DOS and Mac and then Windows 2.
I bought an Acorn Archimedes with RISC OS: a powerful 32-bit RISC home computer with a totally proprietary OS (although it’s still around and it’s FOSS now) descended from a line of microcomputers as old as CP/M, meaning no influence from CP/M or the American mainstream of computers. Very weird command lines, very weird filesystems, very weird editors, but all integrated and very powerful and capable. (It has a very strange two-cursor editing system: one insertion/text entry cursor, and another copy-from editor, and possibly a mouse pointer as well making three).
I killed it by botching a hardware expansion installation, so I bought a 2nd hand PC laptop and put OS/2 2.0 on it. So I had to move to the same tools I used at work on DOS and Windows.
I had to learn to work dozens of different editors with dozens of different UIs because that’s how 1980s computing was. There were no UI standards yet.
But then, everything changed.
What happened in the early 1990s was that the wave of old DOS apps, with strange, idiosyncratic UIs – sometimes inherited from CP/M versions, been ported to DOS (such as WordStar) – ran up against the new wave of standardisation imposed by (classic) MacOS and early Windows (meaning 2 and 3 here, long before Win95).
The GUI OSes that were catching on had standardised UIs.
This meant: standard layouts for menus, contents of menus, for dialog boxes, for keystrokes as well as mouse actions. UIs got forcibly standardised, mostly around IBM CUA – I wrote much of that article – and late-1980s/early-1990s DOS apps mostly had to conform, or die.
And conform they did. Even then-quite-modern apps like WordPerfect gained menu bars and changed their weird keystrokes to conform. If their own weird UIs conflicted, then the standards took over. WordPerfect had a very powerful, efficient, UI driven by function keys. But it wasn’t compatible with the new standards. It used
F3for help andEscapeto repeat a character, command or macro. The new standards saidF1must be help andEscmust be cancel. So WordPerfect complied.And until the company stumbled, porting to OS/2 and ignoring Windows until it was too late, it worked. WordPerfect remained the dominant industry-standard, even as its UI got modernised. Users adapted.
Any you know what? It was great. It was such a relief. I could forget all those weird arcane UIs, because suddenly, DOS or Windows or Mac or OS/2 or whatever, it didn’t matter, Ctrl+O opened a file. Ctrl+S saved it. Ctrl+P printed it. Ctrl+F started a Find. Ctrl+Z/X/C/V always did Undo, Cut, Copy, Paste. Esc closed a dialog box or a prompt or whatever. F1 gave you help.
Today, all modern editors, console or GUI, whatever the GUI, have this UI.
Kate, KWrite, Geany, Leafpad, Mousepad, Notepad, Notepad++, Gedit before GNOME 3 and CSD. They all have the same core UI.
Like it or not, for more than three decades, there’s been a standard language for UIs and so on. “Files”, “windows”, the “clipboard”, “cut”, “copy”, “paste”. Standard menus, in standard positions, with standard commands on them, in a standard order, accessed with standard keystrokes.
And 99% of this applies to Atom, and Sublime Text, and VSCode, and so on. I don’t like any of ‘em much. Atom is the least bad and it’s a bloated mess IMHO. But it’s an Electron app, and they all are.
Eight Megs And Constantly Swapping my a$$. Is that all?
So why am I talking about this?
Because the world of tools like Emacs never underwent this modernisation.
Vi ignores this. Its fans love its power and efficiency and are willing to learn its weird UI.
But Vi (and Vim and Elvis etc.) aren’t very customisable. You can’t easily change their UI. They are what they are.
Emacs ignores this, for the same reasons. The manual and tutorial talk about “buffers” and “scratchpads” and “Meta keys” and dozens of things that no computer made in 40 years has: a whole different language before the Mac and DOS and Windows transformed the world of computing.
But Emacs is customisable. That is a big part of its appeal. It’s infinitely customisable. It’s a whole framework for building apps. It reads mail, and news, and has web browsers, and everything.
What I propose is a wholescale rework of the UI.
cua-modeis not enough.The good news: most of it has been done: it’s called ErgoEmacs. It’s in Melpa, but if you’re not an Emacser already, that’s very hard to install and harder still to set for your regional keyboard layout.
What I propose is twofold.
[1]
Someone starts with another Emacs distro, like Doom or Spacemacs or something, or maybe even a fork, like emacs-ng or commercial-emacs… but aimed at making Emacs look like a standard text editor with a default file type of plain text, not any programming language.
That it defaults to plain text. Not to Lisp, not to any language mode, unless a file with a recognised extension is opened. Plain text in the regional default of that user account. No autocomplete, no highlighting, nothing. Text before anything. Fragments of Lisp being offered and then disappearing as a newbie types are weird and confusing.
On first run, if no config file is found, then by default, it opens in ErgoEmacs’ CUA UI, be that on the console or in the GUI. Standard menus, referring to Ctrl and Alt/Opt and Windows/Super like every keyboard on every computer made since 1985 has. No “meta”. Standard meanings of “windows” and so on.
Same for the manual, tutorial, etc.
I don’t care about themes, dark mode, font rendering, any of that. Anything of that you want, go mad.
But the standard CUA-compliant UI, on by default, no configuration required.
[2]
That all of this vanishes if it’s installed for an existing Emacs user.
If Emacs launches and finds an existing config file, all this stuff is ignored. Go back to the standards. Nothing that in any way inconveniences existing users. That’s really important.
I’m not a big Emacs user. I’m not saying that I don’t like it. Just that I don’t use it that much. I keep it there on my task bar as one of the various editors I use for various jobs. One thing though that would make it increase my personal usage of it though, is speed. But I know that interpreting Elisp is not necessarily quick and writing a new interpreter while making sure to maintain compatibility with the tens of thousands of Elisp extension already in the wild would be highly improbable.
The latest release of Emacs has JIT compilation of elisp: https://www.emacswiki.org/emacs/GccEmacs
There’s some hope on this front, but I’m not holding my breath - https://www.emacswiki.org/emacs/GuileEmacs
The code repos in that link haven’t been touched in seven years.
Hey, you might as well look at Lem: https://github.com/lem-project/lem/ it’s built in CL and it is usable right now, for CL and other languages out of the box. It works on the terminal and it has experimental Electron and OpenGL UIs.
The only core emacs issue I see (having used it for quite a few years now) is the lack of effective threading and UI event loops.
I have a decently sized ~/.emacs file, don’t mind growing it. Emacs is not notepad++, not to be deeply customized.
I need nothing in that list….
I wouldn’t mind deleting a few items from my .emacs because they were standard out of the box.
eg. helm and projectile should be standard (plus a bunch of their addons)
Admittedly I don’t expect everyone to agree on which navigation and narrowing framework, but it would be nice if some of the best were default and the others selectable from the menu instead of install from melpa and configure.
I suspect there are other really good packages I don’t use that I should be using, but they are not part of the standard install and I haven’t understood how good they are.
Building blocks are fine when you got time to build. But nowadays not many do. We have stuff to do, we don’t have time to figure out configurations, unfortunately.
If I would use emacs, i would just use doom-emacs and call it a day.
I have my own neovim config however, because all the configs i could find were full of stuff I didnt need..
If you liked doom-emacs, you might like doom-nvim. Its philosophy is that you can use only what you need from it. Also found kickstart.nvim and neovim-from-scratch useful for writing my own neovim config (well, for “modernising” my previous Vim8 config).
I should give doom-nvim another look then. Didn’t know about kickstart nor neovim-from-scratch, thanks!