Live data from Hacker News

Toward a “modern” Emacs

lwn.net

271–280 of 539 posts

Re: Toward a “modern” Emacs

#271
post #28

I don’t know. I read the whole article and it seems the suggestions boil down to emacs needing to be more “modern” by defaulting to dark mode, making color theming easier, changing right click behavior, the menus, and changing the shortcuts. And the author of the article would like the development process to be more “modern.” Emacs is one of the most successful text editors of all time if not the most successful. It…

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

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

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

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

Re: Toward a “modern” Emacs

#273
post #28

I don’t know. I read the whole article and it seems the suggestions boil down to emacs needing to be more “modern” by defaulting to dark mode, making color theming easier, changing right click behavior, the menus, and changing the shortcuts. And the author of the article would like the development process to be more “modern.” Emacs is one of the most successful text editors of all time if not the most successful. It…

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

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

Re: Toward a “modern” Emacs

#274

Earlier quoted context omitted.

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

Well, Eclipse has had practically two decades of vi/emacs users shitting on it and yet it is still popular enough to warrant an entire conference. https://www.eclipsecon.org/2020

Isn't Eclipse basically the modern Emacs?

It's a plugin management system that happens to be shipped with a set of plug-ins targeted at serving as an IDE, written in Java instead of Lisp.

Re: Toward a “modern” Emacs

#275

Earlier quoted context omitted.

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

Why? How are either of them superior to VS Code?

I know, “memory is cheap,” but still...

Re: Toward a “modern” Emacs

#276

Earlier quoted context omitted.

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

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

You're on the right track. There are really 3 editors in the world: Vim, Emacs, and

Yes, VSCode will be replaced by something newer and flashier, but the learning curve to switch to it will be minimal.

Re: Toward a “modern” Emacs

#277

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

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

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

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

Re: Toward a “modern” Emacs

#278
post #26

Earlier quoted context omitted.

A lot of things are different without being better. Before ctrl-x/Ctrl-v became the standard for Cut/paste, it was Ctrl-del/Ctrl-insert in many dos and early Windows editors - which makes a lot more mnemonic sense. It’s better to standardize on something, but that something isn’t necessarily better and is often worse.

Ctrl+Ins for copy, Shift+Del for cut and Shift+Ins for paste. Still works in Windows. Ctrl+Del deletes a word. DOS editors often used WordStar bindings. C-k C-b to start a block, C-k C-c to copy or C-k C-v to move. Turbo Pascal used these bindings. They're also the default bindings for the `joe` editor.

And Ctrl+Ins, Shift+Del, Shift+Ins work out of the box in (windowed) Emacs, too.

Re: Toward a “modern” Emacs

#279

Earlier quoted context omitted.

thanks, that worked, I was down the auctex rabbit hole, and got stuck on a 'cannot load file... cdlatex' or some such... C-c C-x C-l worked out of box! Weird, once I have C-cxl'ed a fragment to rendered latex, and the C-cc'ed back to monospace, I am no longer able to insert superscript and subscript symbols, and it complains about cdlatex-superscript or cdlatex-sub-superscript...

cdlatex likely is very useful if you plan to edit a lot of formulae. org has its own org-cdlatex minor mode (also needs effort to set up).

reinstalled the org package restarted emacs, and now it works

Re: Toward a “modern” Emacs

#280
post #155

Earlier quoted context omitted.

When you've been warned the world will end and ~~notepad~~ VS code will take over for 50 years you tend to become blase about the whole thing. Emacs has a steep learning curve and that's good. You need a moat to keep the barbarians from destroying your kingdom.

I have used emacs since I was an undergrad, 25+ years ago and I have no plans to switch. That does not stop me from recognizing the fact that VS Code does almost everything that emacs does, often better, has orders of magnitude more users, is much more approachable and is being improved at a much faster rate. As they say, "this time its different".

I've been using Emacs for an entire 1 year and I have to say - I only like OrgMode. I've barely tried out Magit, so maybe that's another killer feature. But for programming, I think that Emacs is too steep a hill to climb when VSCode and JetBrains' IDEs offer so much out of the box or just a few clicks/commands away. In Emacs, you can can, in theory, do anything you like. And it is so impressive when you customize it to behave in a certain way. It's also more open for tweaking than any other editor. 'describe-function' and 'describe-key' are super cool, for example. But VSCode is just more practical. Instead of writing some Elisp (which is an incredibly awkward language) to customize your IDE, you can just go to the extensions screen and very likely find and download an extension that does what you want. Maybe not exactly. Maybe you could make Emacs behave much more precisely, according to your preferences. But you might spend hours, if not days, depending on your level of expertise. Meanwhile, with VSCode, you essentially bypass all that.
Post reply on HN