Toward a "modern" Emacs [LWN.net]

Toward a "modern" Emacs

Posted Sep 25, 2020 18:57 UTC (Fri) by tdz (subscriber, #58733)
Parent article: Toward a "modern" Emacs

I'm not a user of emacs, but from what I heard, emacs is basically a Lisp environment with a text-editor UI on top. Much of the discussion seems focused on the UI side.

How much of emacs is the editor, and how much is the environment? Could they have an entirely separate, 'modern' interface on top of the Lisp interpreter and sell it as 'emacs-light'.

Toward a "modern" Emacs

Posted Sep 26, 2020 4:40 UTC (Sat) by cozzyd (guest, #110972) [Link] (1 responses)

Yes, this is the most sensible thing to--offer an alternative name for emacs with a different configuration mirroring current best practices. The alias would be something hip like emacs.io, eemmaaccssyy or emacshub . On startup it would allocate 500 MB for no reason and spawn a few threads that busy wait on each other so that it has a familiar resource profile to what "modern" users are accustomed to. Of course, it will be a challenge to keep up with whatever the latest trend is, so it probably makes sense to also download the latest and greatest configuration on startup using some insecure bespoke package manager (you can fork pip or npm or whatever is in vogue). If users don't want conflicts from this, they can set up an emacsenv environment for each file they edit, as this seems to be the recommended practice nowadays anyway.

(actually, as a vim user, the main suggestion I'd have for emacs is to have evil mode by default =P).

Toward a "modern" Emacs

Posted Sep 26, 2020 8:08 UTC (Sat) by MKesper (subscriber, #38539) [Link]

No need to be snarky.
Please give doom-emacs a try.
Includes evil-mode, easy configuration and fast startup times though featuring everything that makes Emacs great like magit.

Toward a "modern" Emacs

Posted Sep 26, 2020 11:24 UTC (Sat) by dottedmag (subscriber, #18590) [Link] (3 responses)

What would be the point?

Emacs is used because of accumulated trove of elisp code that covers everything under the Sun.

Read the elisp manual and you'll see that the API to manipulate UI (buffers, windows) is in the heart of it — make a new, incompatible, UI and you'll lose compatibility with all the elisp code written ever except libraries.

Emacs with new incompatible UI is no better than an outdated quirky Lisp VM. One can easily take Clojure and build an editor from it, the results will be identical, except that the language is better.

Toward a "modern" Emacs

Posted Sep 26, 2020 11:59 UTC (Sat) by tdz (subscriber, #58733) [Link] (2 responses)

The point is: if Emacs is primarily a platform, the devs have all the options for overhauling the user interfaces. If Emacs is primarily an editor, possible changes are limited to UI style and theming.

Toward a "modern" Emacs

Posted Sep 26, 2020 15:38 UTC (Sat) by dottedmag (subscriber, #18590) [Link]

It's a lousy platform by standards of 2020. The only redeeming quality of Emacs today is a huge amount of effort that went into editor and modes. Losing backward compatibility with all this code makes Emacs-as-a-platform completely useless.

Toward a "modern" Emacs

Posted Sep 26, 2020 16:29 UTC (Sat) by khim (subscriber, #9252) [Link]

I will try to say what others have said again.

Yes, Emacs is mostly a development platform — and API for that development platform is Emacs UI.

That's the same issue Firefox developers faced and the same issue which made Chrome developers to only offer very limited extensions API: if you give developers an option to change, basically, anything in your app… then suddenly all possible changes in the app become impossible.

That's why, ultimately, what we have now, today, is not Emacs 28, but, in reality Emacs 1.28: the major part of Emacs version number was dropped years ago because you couldn't radically change anything in Emacs.

You can only extend it, not change it.