Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> You do know that there is a middle ground, right? Emacs itself could come with reasonable defaults...

That's the rub though. Emacs could change its defaults, plan large deprecation and rename, rewrite all its documentation and write even more to help migrate. And 20 years from now someone will be whining about the 2010 "web arcana" embedded in some interface and command set.

> newbies wouldn't have to read about 80's computing arcana

Because here's the perfect example. Emacs isn't 80s computing arcana, it's 60s computing arcana largely encoded into it in the 70s. In the early 90s when I first picked it up there was a similar push to encode the arcana from the 80s instead. "Pick the standard keybinds that make sense!" they said. Like Shift-Delete for cut and Shift-Insert for paste!

... oh, that's probably not what you want today either, is it?

So here's your options:

- Churn the defaults and everyone's configs every 15ish years

- Document as best you can the defaults and how to change them, and make the best UIs you can at the time, in fashion or not. (Kill rings are still better than cut buffers!)

Universal "reasonable defaults" don't exist in a tool meant to last 50 years in an ecosystem of fads.



Yeah, but here's the thing. Recently geneticists had to start renaming genes because Excel would parse the gene names as dates. And Excel is supposed to be "software".

At a certain critical mass, soft-ware stops being soft. Other things bend to accommodate the soft-ware.

You know what's even harder than hard soft-ware? Social mores and expectations. For example, such as those formed by millions upon millions of spreadsheet users.

Or billions and billions of web users.

So, where am I going with this? Emacs has encoded some norms from the 60s when the tech community was probably 0.1% of what it is now, and when large numbers of those 0.1% people were technically adept and very flexible in adopting new things.

"Web arcana" has been assimilated by a million more applications and systems than those systems that inspired Emacs had. It has also been assimilated by billions (!) of people.

60s arcana is not equivalent to web arcana, for this reason.


Yeah, sorry, you're right. Now is definitely the end of history and time to rewrite everything into the dominant paradigm.


So it's better if the end of history was the 60s, when there were 10000 programmers, in total, worldwide?

When we hadn't even standardized the keyboard layout and the "display" was a dot matrix printer? When there was no networking to speak of?

How does that make more sense?


It's not like Emacs doesn't deprecate or change anything. It's not like its feature set froze in the 60s. And it's not like it doesn't document how to turn on CUA bindings, or Windows or OS X-compatible bindings, or have special builds or distributions where these are defaults. If you want C-c, C-x, C-v, you can have it. Today. In many distributions, by default. The keybindings are not the main issue either way in how "usable" a tool like Emacs is. If you think they are, you're missing the entire point of how Emacs is special regarding UIs.

I can throw the bullshit rhetoric right back at you: You think absolutely nothing was better in the 60s? That modern IDEs lost nothing compared to the tools of 10, 20, 30, 40, 50 years ago? Why isn't Emacs like Borland? Why isn't Emacs like Visual Studio? Why isn't Emacs like Eclipse? Why isn't it like Mosaic, QuickBasic, Coldfusion? There are reasonable answers to these questions, and they'll tell you also why Emacs isn't like whatever you want to compare it to today.

Maybe Emacs already occupies a local maximum, "a middle ground", taking some of the best compatible ideas from the times it's been alive in. Vi another local maximum. IntelliJ or VSCode, others - but emphasis then on local, and I hope you like retraining.

The problem is not keybindings or what decade its metaphors exist in, it's people see Magit or Org or whatever high-level fully-integrated tool, and want just that. And you don't understand that is an outcome of a path that really does require the whole philosophy to ingest into your workflow. But you don't want to learn the philosophy, you just want to 10x crush git or whatever. No, it won't happen. There's all sorts of dumbass metaphors in in this thread now, but in the end Emacs is garden, not a hammer or a workbench or an oscilloscope or whatever. You get out proportion to what you put in, you work with it not just use it.

Shit's just gonna get faster. You need to find ways to live with it, not copy it. Talk to your fathers-in-law.


I know you're angling for option 2 here, but honestly, default churn still sounds like the best choice. Don't like it? Have a one-line config Defaults=1980 and let people like my father-in-law keep using their Shift-Delete, while the rest of us can enjoy an editor that's at least usable out of the box.


> Have a one-line config Defaults=1980

You could bundle up maybe a dozen keybinds like this, but it's not going to scale to even address the complaints we see in this thread (window vs. frame terminology), let alone the full gamut of mainstream Emacs configuration. And it's a massive amount of work to do. And it's not fundamentally different than just picking an Emacs-distribution-du-jour (Spacemacs, Doom Emacs) right now.

If that's what you want, my view is you might as well be churning whole editors. And truthfully, if that's what you want, do it! But I want a kill ring, and buffer/window management that doesn't presuppose multiple frames, and my mode line. I don't want to waste critical keybindings like C-x or C-c on weaksauce single-buffered text operations. And yeah, there's a lot of things I would change if I was doing "Emacs from scratch", but on the other hand I don't need to because I can change them now, and easily share them, and still take advantage of what everyone else is doing.




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

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

Search: