Toward a "modern" Emacs [LWN.net]

Toward a "modern" Emacs

Posted Sep 29, 2020 17:37 UTC (Tue) by marcH (subscriber, #57642)
In reply to: Toward a "modern" Emacs by pizza
Parent article: Toward a "modern" Emacs

> that someone will have to show how those changes will be an overall improvement _for the existing team_

Totally agreed - as long the existing team doesn't "live under a rock", doesn't place non-technical objectives too far above technical ones and can generally listen to unusual perspectives. Otherwise it would just be a lost cause it would be better to either fork or look for alternatives and not just for tooling reasons.

Another option when you can afford it and when the size of the project justifies it is to "fragment and bridge" the tooling, this is what happens for the kernel for instance.

> and are all volunteers.

Depends on the project.

to post comments

Toward a "modern" Emacs

Posted Sep 29, 2020 17:56 UTC (Tue) by ard (guest, #139727) [Link]

> > that someone will have to show how those changes will be an overall
> improvement _for the existing team_
>
> Totally agreed - as long the existing team doesn't "live under a rock",
> doesn't place non-technical objectives too far above technical ones and can
> generally listen to unusual perspectives.

But who does that? I'm not a member of Emacs core team and never sent
any patches but I'm glad they think about the future, I'd like to see
how Emacs evolves in the next decades. I also described how Emacs
fills all of my needs as a programmer in year 2020, mentioned Emacs SE
(I forgot r/emacs) and stated that there are many other projects that
use e-email and that you should know how to use it. You somehow
focused on that e-mail thing and started convincing me that it's very
very bad and should not be used. Nobody "lives under the rock" here.

> Otherwise it would just be a lost cause it would be better to either
> fork or look for alternatives and not just for tooling reasons.

Emacs has been forked multiple times, and it will be forked multiple
other times if there is a need. For me, making it work on Wayland
without using XWayland is now one of the most important things to
do. I'd gladly start using Wayland on the daily basis without any
leftovers from X.

> Another option when you can afford it and when the size of the project
> justifies it is to "fragment and bridge" the tooling, this is what happens
> for the kernel for instance.

Emacs is, however, a much smaller project compared to kernel
(actually, most OS projects are smaller than kernel). It's also not as
critical and there are not so many eyeballs looking at it.

Toward a "modern" Emacs

Posted Sep 29, 2020 18:25 UTC (Tue) by pizza (subscriber, #46) [Link]

> Otherwise it would just be a lost cause it would be better to either fork or look for alternatives and not just for tooling reasons.

Well, yes -- the developers doing the actual work are the ones who ultimately decide what direction a project takes, up to and including forking it if the nominal "owners" are intransigent.

If RMS is truly the only impediment to "progress" in emacs, then its most productive developers will revolt and fork it. It won't even be the first time this has happened to a core GNU package.