Toward a "modern" Emacs [LWN.net]

Toward a "modern" Emacs

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

> but you cannot say that these things are not used any more.

Good thing no one said that then but please keep arguing with yourself again.

> this is called learning.

I've already used mailing-lists and I'm still using some sometimes. That's why I try to avoid them.

> Everyone uses e-mail though, using mailing list is easy especially if you do not need to subscribe

If you're interested in learning this assumption has already been questioned and discussed a million times on this site - and others.

Random example: https://lwn.net/Articles/817668/

By the way it's not mailing-lists that seem to be losing steam; email as a whole too. "Blame" Facebook, Whatsapp and what not.

> If you don't know how to use a mailing list you will never contribute to Linux or Freebsd kernels or projects such as busybox, U-boot and others.

Exactly one of the top issues that has already been discussed a million times, welcome to the party. Better late than never.

to post comments

Toward a "modern" Emacs

Posted Sep 28, 2020 18:51 UTC (Mon) by ard (guest, #139727) [Link] (9 responses)

> > but you cannot say that these things are not used any more.
>
> Good thing no one said that then but please keep arguing with yourself
> again.

It's either me or you should express your thoughts more clearly.

> > this is called learning.
>
> I've already used mailing-lists and I'm still using some sometimes. That's
> why I try to avoid them.

You see, and I *prefer* using mailing lists over Web-based forums.

> > Everyone uses e-mail though, using mailing list is easy especially if you
> do not need to subscribe
>
> If you're interested in learning this assumption has already been
> questioned and discussed a million times on this site - and others.
>
> Random example: https://lwn.net/Articles/817668/

Wow, if you didn't tell me that I wouldn't even know that
https://discourse.debian.net exists. I have never used Discourse but
I'd gladly start if there was a need but e-mail would still be
better. I can use both - no problem for me but I see that some
self-called "modern" people (not you) are rather close-minded and
inflexible.

> By the way it's not mailing-lists that seem to be losing steam; email as a
> whole too. "Blame" Facebook, Whatsapp and what not.

I don't use e-mail on my phone when I want to ask someone if we hang
out this evening, I use Signal. But e-mail loosing steam? Maybe but
I'm not sure it will stop being relevant until the end of my "career"
but I wouldn't be so sure about Facebooks, Whatsapps and other today's
rockstars. At least, e-mail serves as a login/registration mechanism
and notification system in many places. It's still widely used in
business because it's versatile, unified, independent and secure (but
only if set up correctly).

>
> > If you don't know how to use a mailing list you will never contribute to
> Linux or Freebsd kernels or projects such as busybox, U-boot and others.
>
> Exactly one of the top issues that has already been discussed a million
> times, welcome to the party. Better late than never.

Well, if someone cannot figure out how to use e-mail they'd better not
contribute.

Toward a "modern" Emacs

Posted Sep 28, 2020 20:52 UTC (Mon) by marcH (subscriber, #57642) [Link] (8 responses)

> It's either me or you should express your thoughts more clearly.

I clarified "this is not what I said". pabs gave a good example that I endorsed. Yet you kept at it. If you're not sure what I meant don't keep making me say what you fancy answering instead. This site is one of the few left where people try to understand each other in the comments section.

> It's still widely used in business because it's versatile, unified, independent and secure

I agree with most of your technical description of email here but it doesn't automatically follow that email should be used for everything including code reviews and project collaboration, no more than it implies email is good substitute for databases (which most "modern" tools rely on = not so random example).

> > This assumption has already been questioned and discussed a million times on this site - and others.

Yet I can't resist addressing this particular, knee-jerk justification:

> Well, if someone cannot figure out how to use e-mail they'd better not contribute.

s/figure out/like/

I know how to use email; I even knew how to send a message with telnet 25 and retrieve them on port 110 (before everything became encrypted). I just _prefer_ to avoid email when I can because I find it messy, disorganized and not productive.

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!? That's the worst reason ever and possibly turning off people who like email but not this kind of attitude and to be honest it lowers the credit of other, much better points you made. Don't mix up two totally different problems.

For instance a much better way to filter contributors and save maintainer time is not to start reviewing anything until all tests and checks pass in CI (or have a very good, written justification why they don't). Now you know the wannabee contributor had the technical skills to perform something actually useful and relevant: reproduce and troubleshoot failures and fix them. If no CI failure (for instance because of lack of test coverage), asking for new tests is another much better litmus test.

This is just an example I bet you can find others. BTW any _single_ litmus test carries a "monoculture" risk.

In general creating an artificial shortage of contributors because there is a shortage of maintainers is playing with fire from a long term, natural selection perspective, so proceed very carefully. Even betting you'll be the next "COBOL generation" pulled out of retirement at great expense would be risky ;-) There are many open-source projects to contribute to, many more than ever before and there is a shortage of smart contributors too. So good luck finding your next generation maintainers if you purposely rely on a litmus test as bad as "Do you like email?"

Toward a "modern" Emacs

Posted Sep 28, 2020 21:45 UTC (Mon) by ard (guest, #139727) [Link] (7 responses)

> Yet I can't resist addressing this particular, knee-jerk justification:
>
> > Well, if someone cannot figure out how to use e-mail they'd better not
> contribute.
>
> s/figure out/like/
>
> 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. Well, I did and I'm
not the smartest person in the world, I'm actually quite dumb.

> I even knew how to send a message with telnet 25
> and retrieve them on port 110 (before everything became encrypted).

Cool, I use telnet only for tests. I use Mutt + msmtp + offlineimap +
K-9 Mail on the daily basis.

> I just _prefer_ to avoid email when I can because I find it messy,
> disorganized and not productive.

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'm notified about new e-mails on my
phone; I can read and reply to e-mails on my phone and thanks to IMAP
they are synchronized with mutt) and productive - I don't have to
leave command line and since I use Emacs to write the body I have
access to all existing buffers as I explained above.

> 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!?

As I explained, I find e-mail technically easy to use. I also find web
forms technically use to use though slightly less convenient because I
hate using mouse (I'm using tridactyl in Firefox to overcome this
problem) and because web based forums are not so flexible, cannot be
backed up locally and do not provide as good searching capabilities as
mutt does. So yes, I find e-mail the best way for the project to
communicate.

> That's the worst reason ever and possibly turning off people who
> like email but not this kind of attitude and to be honest it lowers
> the credit of other, much better points you made. Don't mix up two
> totally different problems.

I don't get it.

> For instance a much better way to filter contributors and save maintainer
> time is not to start reviewing anything until all tests and checks pass in
> CI (or have a very good, written justification why they don't).

Yes, this is good.

> Now you know the wannabee contributor had the technical skills to
> perform something actually useful and relevant: reproduce and
> troubleshoot failures and fix them. If no CI failure (for instance
> because of lack of test coverage), asking for new tests is another
> much better litmus test.

ok but what's your point here? Are you saying there is no CI on
mailing lists? There might be - there is one on LKML for example, and
they also have a web based 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).

> This is just an example I bet you can find others. BTW any _single_ litmus
> test carries a "monoculture" risk.
>
> In general creating an artificial shortage of contributors because there is
> a shortage of maintainers is playing with fire from a long term, natural
> selection perspective, so proceed very carefully

But this is not 'artificial shortage of contributors', I don't know
how did you come to this conclusion. What if project A uses Github but
someone who wants to contribute used to work for years in project B
that uses Gerrit and doesn't know how Github works (and these 2 tools
are really different technically) - is project A intentionally
creating shortage of contributors this way?

> Even betting you'll be the next "COBOL generation" pulled out of
> retirement at great expense would be risky ;-)

Don't worry about me, I have to work for another 35 years to achieve
retirement age. I expect to see a lot of breakthrough changes, new
ways of doing things, new ideas and adapt to all of them. Just a few
months ago I switched to i3 to be ready to switch to Sway on Wayland
and a few days ago I got a new M.2 SSD disk, much faster than the ones
I have used so far. I'm not and am not planning on being stuck in the
past.

> There are many open-source projects to contribute to

I know, I contributed to many.

> many more than ever before

There are many although their quality and usefulness vary.

> and there is a shortage of smart contributors too.

Smart contributors - yes, smart.

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

Toward a "modern" Emacs

Posted Sep 28, 2020 22:57 UTC (Mon) by marcH (subscriber, #57642) [Link] (6 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:

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

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:

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.