[AJRF]

I use emacs daily and have done for 5+ years now. Even with that, It's undeniable that it makes some tragic choices that keep it from being popular in the modern day.

You see every few years a project to modernize emacs and get wider mindshare among developer community, and they always fail due to some stubborn choices due to stalwarts not admitting when they are wrong.

I have more faith in VSCode sticking around for the next 10 years than I do Emacs.

[Koshkin]

I am sure emacs will be alive and well in 20 years. (8MB and constantly swapping and all…)

[natrys]

> I have more faith in VSCode sticking around for the next 10 years than I do Emacs.

I mean, almost everyone is confident about that too. And rightfully so because, VSCode actually has real corporate backing. People are being actually paid to develop it and sometimes plugins for it, so it would be a surprise if it didn't pan out. Nobody is getting paid to work on Emacs, or third party elisp libraries. It has always been individual hackers doing the bits that interests them. I don't want to come across like anybody owes Emacs anything. But I think in forums people sometimes take the reverse for granted, like Emacs owes anyone anything. Or that the people who actually bother to do voluntary work share the same vision of modernity as them, so it's a failure of some sort when that isn't exactly delivered.

> You see every few years a project to modernize emacs and get wider mindshare among developer community, and they always fail due to some stubborn choices due to stalwarts not admitting when they are wrong.

I think this is a mischaracterisation. Because, firstly you don't actually need the approval of the "stalwarts" to modernise it. Doom Emacs is making a name of its own just fine. The other thing is, Emacs is old. Most of the old vanguards aren't actively involved in Emacs development any more. Most of the "stalwarts" now weren't even around for most of the mistakes, why would you attribute things to vanity when it was not current stalwarts personally who were responsible for most of the design goals?

Browsing emacs-devel, it's clear that the real problem is acute lack of manpower. Only a fraction of Emacs users do bug reports, and then only a tiny fraction of them do actually get involved in fixing things. Which means the maintainers are always facing an uphill battle, who by the way don't have domain expertise or historical understanding of why things are the way they are, any more than you or I do, in many of the situations. Compared to that, VSCode is only a few years old, there are probably engineers who are familiar with the entire codebase, from conception to now.

That said, it has always been more or less like this. Emacs will be fine in its own way, because it will always attract certain sort of hackers. So sure, in terms of "mindshare" and "percentage of users", Emacs will keep free falling, specially now that software development itself has become way more pervasive. It might continue to get more out of touch with "modernity". However, as someone who has been in Emacs community for 7 years now, I believe the ecosystem is only getting more and more vibrant each year than the one before, in absolute terms (more mailing list or other forum activities, more landmark features, more new and high quality third party libraries etc.).

[jimmyvalmer]

> like Emacs owes anyone anything.

The vast majority of users get their emacs from the Linux distributions, who in turn get it from the GNU people. To the extent they've monopolized that distribution channel, the maintainers owe us something. They alone can revive emacs's fortunes, or squander its good name by failing to keep with the times.

[natrys]

> To the extent they've monopolized that distribution channel, the maintainers owe us something. They alone can revive emacs's fortunes, or squander its good name by failing to keep with the times.

I don't even know how that makes any logical sense. The maintainers aren't what they are by virtue of nepotism. Rather they are only one who shows up, voluntarily. That doesn't mean they owe anyone shit, nor does it mean they are preventing others like you to show up and do what needs to be done. So no, if there is anyone who can "revive" Emacs' fortunes, it's people like you, that is if they bother to show up instead of complaining which is always easy.

I also don't get your obsession with "name". XEmacs was a fork, and for a while it was wildly popular. So if you have fundamental difference with emacs-devel, then go fork it? If your fork becomes worthy and solves many people's problems, then all linux distributions will package yours too.

The entire Guile Emacs thing was a product of a GSoC project, the moment it ended so did the project. None volunteered to take up the mantle, even though to this day people lament in forums about how it never became a thing. Turns out that solutions don't magically manifest without people putting the work, what a surprise. But I suppose this is to be expected, when people become too spoiled by other people's labour.

[Jtsummers]

It's OSS, people can and have forked it before, if the present (primary) maintainers aren't doing what people want then they can do it themselves. In the meantime, quite a few people are using emacs as it is and it is getting updates that people seem to care about (like native compilation of elisp).

[jimmyvalmer]

Okay, you obviously missed my point about owning the distribution channel.

[Jtsummers]

They don't own it in any meaningful sense. They do not prevent others from distributing variations and forks via those same channels. It's not like Apple or MS who would sue someone for releasing "Xcode-but-not" or "Visual Studio but not". That's the beauty of OSS. Until you pay them or your desires otherwise align with theirs they don't have to do anything for you, but you aren't prevented from doing it yourself.

[jimmyvalmer]

Okay, I'll make sure Ubuntu's next release puts my fork of emacs in /usr/bin instead of Gnu's. If you're still not understanding this, you might read Nudge by Thaler and Sunstein.