Nah I don't use emacs cos I want lisp. I use it because it was the only thing that made any sense at all on the HP-UX machines I got access to back in 1993. A side effect of that is that emacs does everything I need (with a little bit of pandoc on the side), and I haven't had to learn anything new since.

> A side effect of that is that emacs does everything I need

I'm certain you're telling the truth. And I'm sure that's the case for a lot of old-timers emacs users. But I have the feeling it's less and less true.

People that have used emacs for a long time don't need anything else, so they don't want any change.

People for whom emacs doesn't cover everything want change, but clash against the first group of people (who have been there/contributed for longer), and in the end migrate somewhere else.

I slowly moved everything I need into emacs. That's not because it's superior in all places. It's just that it's the same interface, all the time for me. So I don't have to learn a new editor every now and then.

But my way of working is : many little projects in various languages, much text reports with Latex/markdown, lots of notes (orgmode), bit of email, bit of IRC. In a traditional business, I'd had to use beefier IDE such as IntelliJ (hat beats emacs without a doubt) and maybe Word. But for the rest, emacs fills all the little holes...

One area where I find emacs lacking is appointment (org mode is too big for little things such as quick reminders for today's stuff); a good calculator (calc is very clumys if you compare it to SpeedCrunch for example); a good calendar (emacs calendar is a nightmare to use, for exampe why on earth doesn't display what happens in a day below the calendar and instead forces me to hit 'd' which opens a new mostly empty buffer...); a good console on Windows (on Linux vterm is mostly perfect). Email support is OK with Wanderlust but a nightmare to set up.

Also, since it's very old, there's this warm comforting feeling that will last forever. And also I'm GPL zealot, which helps too :-)

I've used Emacs for 2 years and haven't had to write a single elisp function.

I've used Emacs for... 10 years now? I didn't customize it for an embarrassing long amount of time, but by now I'm comfortable writing elisp code. It is a game changer.

Given enough time I can make Emacs do pretty much anything. I just don't have that much free time (anymore).

I like Emacs for everything except elisp. I never learnt it despite a few attempts, it feels odd and orthogonal to everything else I do. My .emacs is cobbled together from googled snippets.

I would love a normal extension language, that also isn’t a hack (like Python integration). I’m not a JS guy but I’ll take it over lisp.

I’m not sure what the web render things are, but if it means some kind of browser integration, that sounds good too. I use org mode, often with html export and latex maths, having it render quickly and seamlessly would be a win for me.

basically this means that `apt install emacs-nox` now takes 2GBs of downloads, pulls in hundreds of fast-changing, hardly audited extensions and probably is not available in sane distros. No, thanks.

Well, that would be bad, agreed. But as I see upside in the project, I certainly won't bemoan it as useless ahead of time.

The demand for lisp in emacs is overrated by a vocal minority. Most people using emacs do it for the things which are not lisp-specific. The features, the plugins, the community. All that works without touching elisp as a user. And even the swallow elisp-contact that most user have when writting their init.el could be done with any other language.

Though, it's true that the many elisp-code around usca heavy burden. But how much of that is actually still used? And how fast would a propsering community replace them really? Hacking-friendly tools tend to have a wild growing ecosystem. Emacs itself is not shy of having many clones of similar featursets and regular new implementations of old but still popular features.

In that view I don't thing a new language would a real problem long term for the prosperty of emacs. It might be even a benefit, as it mixes in new blood, more people and a broader ecosystem from outside the emacs-scope.

Emacs speed was good enough 45 years ago, with modern processors it's just lightning fast.

You can have C / Rust / any_lang extensions like RipGrep to boost some intensive workloads as well.

I don't know if I agree with this. I love Emacs and nothing has convinced me to give up on it yet, but it is a chore to use on large projects. Helm, projectile and the likes always work with passable performance at worst, but opening a jsx file for the first time literally freezes the entire program for 5 seconds. It's really annoying and I've no idea what causes it.

“Eight megs and constantly swapping” isn’t as much of an issue these days, it’s true...

Eight megs fit in the L3 cache nowadays :)

>Emacs speed was good enough 45 years ago

Uh, in the age of the 386 and 4MB of RAM, if you had that setup against a 486 an 8MB, you chose between running X and running Emacs. OFC you could run jmacs perfectly.

Rust isn't "thrown in", it's what Deno is built with.

No, Deno is built with V8, and V8 is written in C++.

V8 is the only C++ component of Deno. The other bits of the runtime are written in Rust, and Rust is the native extension language.

The "other bits" are the ones that don't matter.

It's like saying that a browser skin is "built on Rust" when inside it's still Webkit and Chromium.

This doesn't require rewriting extensions, it is backwards compatible.

It does not improve elisp performance, however. So it's pointless for those who use and rely on elisp.

I don’t think that’s a fair characterization, you should be able to redefine widely-used Elisp functions to run in deno. One that immediately comes to mind is the crappy HTTP client that Emacs ships with. (I have not tried this, just speaking hypothetically.)

... That still isn't an improvement of elisp speed. It might improve the performance of Emacs, but it's not improving the performance of elisp.

Now we're just quibbling. No it doesn't improve the speed at which the Elisp interpreter can churn through Elisp bytecode. We can however dynamically improve the speed at which some Elisp functions return, which would have the net effect of speeding up consuming Elisp code.