5 ms·

Well, basically this is someone trying to implement VSCode in Emacs ... Ain't gonna get far once the main developer loses interest in the project. Emacs users

by janoc 6y ago

Well, basically this is someone trying to implement VSCode in Emacs ... Ain't gonna get far once the main developer loses interest in the project. Emacs users use Emacs because they want Lisp and don't care about web rendering and javascript runtimes ... Oh yeah and Rust is thrown in too for good measure. Good 90% of Emacs code is in the extensions which are in Lisp and nobody is going to rewrite them to Javascript even if the code was running 50x faster.

usbline 6y ago
Rust isn't "thrown in", it's what Deno is built with.
- otabdeveloper4 6y ago
  No, Deno is built with V8, and V8 is written in C++.
  - bitwize 6y ago
    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.
    - otabdeveloper4 6y ago
      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.
singingfish 6y ago
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.
- monsieurbanana 6y ago
  > 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.
  - wiz21c 6y ago
    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 :-)
  - Kaze404 6y ago
    I've used Emacs for 2 years and haven't had to write a single elisp function.
    - monsieurbanana 6y ago
      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).
cle 6y ago
This doesn't require rewriting extensions, it is backwards compatible.
- dleslie 6y ago
  It does not improve elisp performance, however. So it's pointless for those who use and rely on elisp.
  - cle 6y ago
    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.)
    - dleslie 6y ago
      ... 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.
      - cle 6y ago
        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.
achempion 6y ago
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.
- steveklabnik 6y ago
  “Eight megs and constantly swapping” isn’t as much of an issue these days, it’s true...
  - guerby 6y ago
    Eight megs fit in the L3 cache nowadays :)
- Kaze404 6y ago
  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.
- anthk 6y ago
  >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.
rich_sasha 6y ago
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.
- fock 6y ago
  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.
  - rich_sasha 6y ago
    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.
slightwinder 6y ago
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.

by janoc 6y ago

usbline 6y ago

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

otabdeveloper4 6y ago
No, Deno is built with V8, and V8 is written in C++.
- bitwize 6y ago
  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.
  - otabdeveloper4 6y ago
    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.

singingfish 6y ago

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.

monsieurbanana 6y ago
> 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.
- wiz21c 6y ago
  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 :-)
- Kaze404 6y ago
  I've used Emacs for 2 years and haven't had to write a single elisp function.
  - monsieurbanana 6y ago
    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).

cle 6y ago

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

dleslie 6y ago
It does not improve elisp performance, however. So it's pointless for those who use and rely on elisp.
- cle 6y ago
  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.)
  - dleslie 6y ago
    ... 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.
    - cle 6y ago
      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.

achempion 6y ago

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.

steveklabnik 6y ago
“Eight megs and constantly swapping” isn’t as much of an issue these days, it’s true...
- guerby 6y ago
  Eight megs fit in the L3 cache nowadays :)
Kaze404 6y ago
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.
anthk 6y ago
>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.

rich_sasha 6y ago

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.

fock 6y ago
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.
- rich_sasha 6y ago
  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.

slightwinder 6y ago

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.