Toward a "modern" Emacs [LWN.net]

Toward a "modern" Emacs

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

> I shared a number of references but it doesn't seem you tried to read any other post. You're only interested in explaining how perfect email is (for you).

I should point out here that his comfort with email is fine, just as the email-centric development model of emacs (or whatever) is also fine -- it serves those doing the work quite well. Indeed, hyper-customizable tooling is the entire raison d'etre of emacs, and non-email server-based workflows invariably require using someone else's tooling.

If someone wishes those folks to change a development model/methodology they personally find very productive (and aligns with their overall principles) for something significantly different, that someone will have to show how those changes will be an overall improvement _for the existing team_ -- they are, after all, the ones who are doing the work, and are all volunteers.

Anyway.

to post comments

Toward a "modern" Emacs

Posted Sep 29, 2020 17:37 UTC (Tue) by marcH (subscriber, #57642) [Link] (2 responses)

> 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.

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.