Toward a "modern" Emacs [LWN.net]

Toward a "modern" Emacs

Posted Sep 28, 2020 22:57 UTC (Mon) by marcH (subscriber, #57642)
In reply to: Toward a "modern" Emacs by ard
Parent article: Toward a "modern" Emacs

> > I know how to use email;

> Everybody does. And I didn't mean that YOU don't know how to use e-mail - I meant that if someone wants to contribute to a project that uses e-mail they should be intellectually able to figure out how to use their e-mail client, git-send-mail and git-am.

This is not really about configuring an email client or using git. It's about organizing the information overload you're describing:

> And I find e-mail something completely opposite - organized (mutt has good searching capabilities: I can filter e-mails by From: or To: headers, by subject, by e-mail body; I can move e-mails to other mailboxes; can easily backup my ~/.muttmail even though all messages are also kept on the server;

I prefer not having to do most of these _at all_.

BTW referring to mutt in a discussion about ease of use is... interesting?

> As I explained, I find e-mail technically easy to use.

Great but this discussion isn't about you cause you already prefer email.

> I also find web forms technically use to use though slightly less convenient because I hate using mouse

You just hit the second most common misconception in this discussion. While the web is clearly the preferred database interface these days, there's no fundamental requirement for it to be. If some people manage to get something out of github from Emacs (github = the closed source poster child of open source), surely it's possible to do even better with alternatives to github.

> ok but what's your point here? Are you saying there is no CI on mailing lists?

Again, no idea how you got that. Information overload?

> they also have an interface that shows all patches sent, their state and shows the discussion https://lore.kernel.org/patchwork/project/lkml/list (I heard managers like it this way).

Exactly: this as close to "modern" as kernel development gets. Re-constructing a missing code review database from loose emails as opposed to having some sort of email (and other) interfaces from a code review database like everyone else does. A code review database means someone joining the project 2 years later and debugging a long standing issue can find all the relevant information and barely any irrelevant information in a jiffy. No email organization needed. Meanwhile: https://lwn.net/Articles/797613/

Also: https://damien.lespiau.name/posts/2016-02-13-augmenting-m...

> is github project A intentionally creating shortage of contributors this way?

Yes but not intentionally and (IMHO) not as much as with email. I mean I've never read this: "Well, if someone cannot figure out how to use github they'd better not contribute." In fact github's constant efforts are the exact opposite of that.

> > There are many open-source projects to contribute to

> I know, I contributed to many.

Just to be clear: I meant including many that do not require email.

> > So good luck finding your next generation maintainers if you
> > purposely rely on a litmus test as bad as "Do you like email?"

> I don't do that.

I'm pretty sure you just did.

Also sure you still have a lot of past discussions to catch up with. Write less and read more (and more slowly).

to post comments

Toward a "modern" Emacs

Posted Sep 28, 2020 23:33 UTC (Mon) by ard (guest, #139727) [Link] (5 responses)

> > > I know how to use email;
>
> > Everybody does. And I didn't mean that YOU don't know how to use e-mail -
> I meant that if someone wants to contribute to a project that uses e-mail
> they should be intellectually able to figure out how to use their e-mail
> client, git-send-mail and git-am.
>
> This is not really about configuring an email client or using git. It's
> about organizing the information overload you're describing:

Information overload? E-mail contains From:, To:, Subject: and
body. How is this different from anything else?

> > And I find e-mail something completely opposite - organized (mutt has
> good searching capabilities: I can filter e-mails by From: or To: headers,
> by subject, by e-mail body; I can move e-mails to other mailboxes; can
> easily backup my ~/.muttmail even though all messages are also kept on the
> server;
>
> I prefer not having to do most of these _at all_.

You don't have to do that, you can. And what exactly would you prefer
not having to do? You prefer not doing backup ("there are two kinds of
people...")? You prefer not having easy searching by author or
subject? You prefer not using your smartphone? You prefer not using
the command line? You hate synchronization and notifications?

> BTW referring to mutt in a discussion about ease of use is... interesting?

Sorry, "easy to use" might mean something completely different to
different people, don't you think? For instance, I find Gmail flashy
clicky web interface absolutely disgusting and unusable.

>
> > As I explained, I find e-mail technically easy to use.
>
> Great but this discussion isn't about you cause you already prefer email.

You asked me:

> I perform a number of code reviews daily and I can understand the
> temptation not to make too easy to contribute but seriously: use email
> because you think it's the best way for the project to communicate, not
> because there are technically easier ways to communicate!?

and so I answered.

> > I also find web forms technically use to use though slightly less
> convenient because I hate using mouse
>
> You just hit the second most common misconception in this discussion. While
> the web is clearly the preferred database interface these days, there's no
> fundamental requirement for it to be. If some people manage to get
> something out of github from Emacs (github = the closed source poster child
> of open source), surely it's possible to do even better with alternatives
> to github.

Surely it's also possible with e-mail. BTW, I have never wished to use
Github from Emacs. You can use Github like a regular repository and
you can use hub command line tool to fork and push pull requests
etc. and you can read and reply to all tickets by e-mail.

> > ok but what's your point here? Are you saying there is no CI on mailing
> lists?
>
> Again, no idea how you got that. Information overload?

> Just to be clear: I meant including many that do not require email.

There are no projects that do not require e-mail because you have to
use e-mail to register. Yes, I've used Gerrit, Gitlab, Github and
Bitbucket. I also use StackExchange a lot (Emacs has a very nice
Markdown mode) - it's heavily web based. But what's the point? I have
used many different things, have self-called "modern" developers too?

> > > So good luck finding your next generation maintainers if you
> > > purposely rely on a litmus test as bad as "Do you like email?"
>
> > I don't do that.
>
> I'm pretty sure you just did.

No. Use the right tool for the job. If you want to contribute, follow
the rules. You don't have to like them, it's not your project.

> Also sure you still have a lot of past discussions to catch up with. Write
> less and read more (and more slowly).

Honestly, I have a very hard time trying to understand your
posts. They're patronizing and written in a very bizarre way.

Toward a "modern" Emacs

Posted Sep 29, 2020 15:30 UTC (Tue) by marcH (subscriber, #57642) [Link] (4 responses)

> Honestly, I have a very hard time trying to understand your posts.

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

Toward a "modern" Emacs

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

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

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.