6 ms·

The main advantage Emacs has over other, more modern IDEs is ELisp, and the vast ecosystem built around it. I don't see how supplementing ELisp with JS would ma

The main advantage Emacs has over other, more modern IDEs is ELisp, and the vast ecosystem built around it. I don't see how supplementing ELisp with JS would make Emacs more attractive; most of Emacs' shortcomings originate elsewhere: single-threaded core, IO-blocks-UI, ELisp defaulting to dynamic scoping, bad defaults in general, poor OS/GUI integration, antiquated nomenclature, and just the sheer number of third-party packages and config tweaking that it takes to bring features that should work out of the box (sane dired, LSP, (ma)git, tabs, etc). Emacs desperately needs to deal with its tech debt, but adding a new language runtime without addressing the mountain of architectural issues is just circling around the problem, without actually even looking at it. Hats off for the effort but I'll pass.

bvaldivielso 3y ago
> IO-blocks-UI This is one of the things that _are_ addressed by the project. Regarding your broader point, I don't know if adding a new language would/will help emacs or not but it's _plausible_ something like that would work. The plugin ecosystem in the vim world became more vibrant once writing them in lua was an option.
- funcDropShadow 3y ago
  > I don't know if adding a new language would/will help emacs or not but it's _plausible_ something like that would work. I don't think it is plausible. Emacs extensibility and power stems from the fact you can see and change almost everything. You can add advice, i.e. modify, any function there is. And you can inspect any object that exists in the heap. If you add another language into the mix, these two languages either have to share an object/data structure model or they have to bridge them somehow. In vim you have plugins that add new commands, or hook into some callbacks. But in emacs you can extend every third-party functionality with another third-party library. Fragmenting the ecosystem into two language camps would probably diminish this advantage.
johanvts 3y ago
Agreed, but I think the defaults aren’t that bad. It should not be an IDE or git UI out of the box IMO. What’s needed is better default completion and discoverability.
0xpgm 3y ago
> tweaking that it takes to bring features that should work out of the box (sane dired, LSP, (ma)git, tabs, etc). For LSP (language server protocol), eglot worked out of the box quite well once installed. It ships by default in emacs in the latest versions.
- deleted 3y ago
  [deleted]
- dleslie 3y ago
  It's part of Emacs 29, so it's in Emacs out of the box now.
darau1 3y ago
I say this as a software developer using Emacs daily as my IDE: emacs is not an IDE -- at least not OOTB. It can become a competent IDE, but that isn't what it's built for. Instead, I think of Emacs as an overengineered elisp REPL. That said, I would love to see the issues you mentioned addressed, and would love to see how the EAF[1] does in the future. [1]: https://github.com/emacs-eaf https://github.com/emacs-eaf
- otabdeveloper4 3y ago
  Emacs is just a text editor. And that's okay.
PurpleRamen 3y ago
> The main advantage Emacs has over other, more modern IDEs is ELisp, and the vast ecosystem built around it. Ecosystem yes, and also it's architecture and culture. ELisp I would say no. If we ignore the specific flavor, then 99% of what's realistically done with with elisp, is also covered by other dynamic languages like JavaScript. And the rest is so esoteric that it's probably not that worth the trouble. > I don't see how supplementing ELisp with JS would make Emacs more attractive; Not everyone likes lisp, not everyone is willing to learn a new strange language for unknown benefits. And JS has a vast ecosystem of its own. Far bigger even that Emacs heritage, but on different areas. A well working combination of both, with no side making significant sacrifices, could be very alluring for many more people than Emacs has now.
- mtlmtlmtlmtl 3y ago
  I think it's fine for Emacs to be Emacs. It's basically a museum piece from the Lisp Machine era at this point. There are so many choices already if you insist on javascript. Adding it to Emacs feels like the programmer's equivalent of putting a giant neon sign atop the Pyramid of Khufu; it just doesn't belong there. Emacs is unique and I'd like to preserve that.
  - PurpleRamen 3y ago
    A Museum is fancy storage for unused things. But Emacs is full of very useful and still usable parts, and a useful philosophy and prospering culture. What's wrong with spreading all this to other spaces, and letting other people learn about them, making them more accessible? Works well for (neo)vim. They have moved beyond lousy vim-key-implementations and today people are able to learn about modal editing and composable commands on a good level.
    - mtlmtlmtlmtl 3y ago
      Please don't misunderstand my use of the word "museum". I'm not saying Emacs is useless or that we should never improve or use it. But Emacs is more or less the only surviving relic of a very different paradigm of doing computing and software, one which many of us still cherish. >What's wrong with spreading all this to other spaces, and letting other people learn about them, making them more accessible? Because the philosophy of Emacs and the computing tradition it grew out of is fundamentally at odds with those other spaces. Everything being in one dynamic language is a huge and intrinsic part of that tradition. I suppose you could write an Emacs entirely in javascript if you wanted to, if you followed the same software philosophy. But personally I think Javascript is such an inelegant language that a lot of the power of the idea would be lost even in that case.
pjmlp 3y ago
Back in the day, I was mostly an XEmacs user as it did provide some niceties that Emacs lacked, including being closer to the Windows based IDEs. Not sure how much of it has eventually become part of it, as I seldom use Emacs, even though 10 years of usage leave their mark on the brain. :) I see Emacs finally adopting Guile as a much better path going forward, than attempts like these.
danShumway 3y ago
Genuine question, not trying to be snarky: isn't JS a great way to address most of those concerns that you list? Deno and WebRender have good integration with workers, webrender offers the option of providing better GUI integration (although it's not clear exactly how it will be leveraged), jumping to Javascript gets rid of dynamic scoping, and (in my experience, although mileage may very much vary) tends to handle IO-blocking better. The project's performance justifications it lists are: > Async I/O from Deno, WebWorkers, and WebAsm, gives you the tools to make Emacs a smoother and faster experience without having to install additional tools to launch as background processes or worry about shared library versions. I don't disagree necessarily, in some ways adding another language instead of fixing the one that's still going to be the dominant way most integration is handled is a very, for lack of a better word, temporary fix. If Lisp isn't good enough for an editor, then we'd all jump ship to VSCode or whatever. There is something hacky about saying, "we're not leveraging this language well, let's just add another." But even saying that, I do still (at least at first glance and without looking into it harder) see the appeal. Even dropping the JS entirely, WASM workers seem like a non-terrible way to get better worker support and to get rid of the IO-blocking-UI problem (which I agree is a problem, and might be one of my biggest criticisms of Emacs). Am I missing something?
- admax88qqq 3y ago
  I honestly don't think IO-blocking-UI is such a big issue. And if you try to solve it using workers you introduce an annoying programming paradigm of async/await and IPC. Copying data over IPC can be slow, and having to set up IPC to share the data you need to run in a worker is also annoying. The great thing about the single threaded shared memory model of elisp is that it's a lot easier to code against. And yeah sometimes someone blocks the UI doing synchronous I/O, but that comes at the benefit of making it really easy for people to write addons that do all sorts of things. A lot of the I/O blocking UI problems could be alleviated by just moving to async I/O primitives without incurring the runtime and developer experience problems of a multi process architecture
  - danShumway 3y ago
    Hrm. I don't know if I agree with this or not. Your last sentence is 100% spot on. But at the same time, I've used Emacs as a window manager before, and the reason I stopped was because of IO blocking the UI. I could not handle having a process bug out and having it freeze my entire window manager, and it happened frequently. I don't want to dismiss the argument; maybe it's just that Emacs packages are bad at avoiding that behavior? But I'm not sure that async I/O primitives are enough for a text editor, even though I would generally agree with you. On the subject of that last sentence: > A lot of the I/O blocking UI problems could be alleviated by just moving to async I/O primitives without incurring the runtime and developer experience problems of a multi process architecture This sounds like an advertisement for Javascript to me? This is one of the reasons I think why NodeJS became so popular when it was first introduced, literally because it was single-threaded with good async I/O primitives (or good enough, this was before Promises were in the language), and that led to huge performance improvements over other server implementations that prioritized workers. So while I still don't like the kitchen sink approach, I'm still left feeling like a lot of the problems and solutions being proposed here are kind of things that would be addressed by using Deno in Emacs? At least, I'm seeing the appeal. Single-threaded memory pool to help make developer experience better and to improve performance, coupled with decent async I/O primitives -- that's Javascript, that's one of the things the language is sort of good at. You have workers for larger tasks, and that's definitely handy, but most of your programming is happening in a single-threaded event loop using promises. If I looked at this sentence in isolation, I would think that you were arguing in favor of adding Deno.
dleslie 3y ago
If Emacs moved away from Lisp I would simply stop using Emacs. It's a key factor in why I use Emacs instead of NeoVim, or VSCode.

bvaldivielso 3y ago

> IO-blocks-UI This is one of the things that _are_ addressed by the project. Regarding your broader point, I don't know if adding a new language would/will help emacs or not but it's _plausible_ something like that would work. The plugin ecosystem in the vim world became more vibrant once writing them in lua was an option.

funcDropShadow 3y ago
> I don't know if adding a new language would/will help emacs or not but it's _plausible_ something like that would work. I don't think it is plausible. Emacs extensibility and power stems from the fact you can see and change almost everything. You can add advice, i.e. modify, any function there is. And you can inspect any object that exists in the heap. If you add another language into the mix, these two languages either have to share an object/data structure model or they have to bridge them somehow. In vim you have plugins that add new commands, or hook into some callbacks. But in emacs you can extend every third-party functionality with another third-party library. Fragmenting the ecosystem into two language camps would probably diminish this advantage.

johanvts 3y ago

Agreed, but I think the defaults aren’t that bad. It should not be an IDE or git UI out of the box IMO. What’s needed is better default completion and discoverability.

0xpgm 3y ago

> tweaking that it takes to bring features that should work out of the box (sane dired, LSP, (ma)git, tabs, etc). For LSP (language server protocol), eglot worked out of the box quite well once installed. It ships by default in emacs in the latest versions.

deleted 3y ago
[deleted]
dleslie 3y ago
It's part of Emacs 29, so it's in Emacs out of the box now.

darau1 3y ago

I say this as a software developer using Emacs daily as my IDE: emacs is not an IDE -- at least not OOTB. It can become a competent IDE, but that isn't what it's built for. Instead, I think of Emacs as an overengineered elisp REPL. That said, I would love to see the issues you mentioned addressed, and would love to see how the EAF[1] does in the future. [1]: https://github.com/emacs-eaf https://github.com/emacs-eaf

otabdeveloper4 3y ago
Emacs is just a text editor. And that's okay.

PurpleRamen 3y ago

> The main advantage Emacs has over other, more modern IDEs is ELisp, and the vast ecosystem built around it. Ecosystem yes, and also it's architecture and culture. ELisp I would say no. If we ignore the specific flavor, then 99% of what's realistically done with with elisp, is also covered by other dynamic languages like JavaScript. And the rest is so esoteric that it's probably not that worth the trouble. > I don't see how supplementing ELisp with JS would make Emacs more attractive; Not everyone likes lisp, not everyone is willing to learn a new strange language for unknown benefits. And JS has a vast ecosystem of its own. Far bigger even that Emacs heritage, but on different areas. A well working combination of both, with no side making significant sacrifices, could be very alluring for many more people than Emacs has now.

mtlmtlmtlmtl 3y ago
I think it's fine for Emacs to be Emacs. It's basically a museum piece from the Lisp Machine era at this point. There are so many choices already if you insist on javascript. Adding it to Emacs feels like the programmer's equivalent of putting a giant neon sign atop the Pyramid of Khufu; it just doesn't belong there. Emacs is unique and I'd like to preserve that.
- PurpleRamen 3y ago
  A Museum is fancy storage for unused things. But Emacs is full of very useful and still usable parts, and a useful philosophy and prospering culture. What's wrong with spreading all this to other spaces, and letting other people learn about them, making them more accessible? Works well for (neo)vim. They have moved beyond lousy vim-key-implementations and today people are able to learn about modal editing and composable commands on a good level.
  - mtlmtlmtlmtl 3y ago
    Please don't misunderstand my use of the word "museum". I'm not saying Emacs is useless or that we should never improve or use it. But Emacs is more or less the only surviving relic of a very different paradigm of doing computing and software, one which many of us still cherish. >What's wrong with spreading all this to other spaces, and letting other people learn about them, making them more accessible? Because the philosophy of Emacs and the computing tradition it grew out of is fundamentally at odds with those other spaces. Everything being in one dynamic language is a huge and intrinsic part of that tradition. I suppose you could write an Emacs entirely in javascript if you wanted to, if you followed the same software philosophy. But personally I think Javascript is such an inelegant language that a lot of the power of the idea would be lost even in that case.

pjmlp 3y ago

Back in the day, I was mostly an XEmacs user as it did provide some niceties that Emacs lacked, including being closer to the Windows based IDEs. Not sure how much of it has eventually become part of it, as I seldom use Emacs, even though 10 years of usage leave their mark on the brain. :) I see Emacs finally adopting Guile as a much better path going forward, than attempts like these.

danShumway 3y ago

Genuine question, not trying to be snarky: isn't JS a great way to address most of those concerns that you list? Deno and WebRender have good integration with workers, webrender offers the option of providing better GUI integration (although it's not clear exactly how it will be leveraged), jumping to Javascript gets rid of dynamic scoping, and (in my experience, although mileage may very much vary) tends to handle IO-blocking better. The project's performance justifications it lists are: > Async I/O from Deno, WebWorkers, and WebAsm, gives you the tools to make Emacs a smoother and faster experience without having to install additional tools to launch as background processes or worry about shared library versions. I don't disagree necessarily, in some ways adding another language instead of fixing the one that's still going to be the dominant way most integration is handled is a very, for lack of a better word, temporary fix. If Lisp isn't good enough for an editor, then we'd all jump ship to VSCode or whatever. There is something hacky about saying, "we're not leveraging this language well, let's just add another." But even saying that, I do still (at least at first glance and without looking into it harder) see the appeal. Even dropping the JS entirely, WASM workers seem like a non-terrible way to get better worker support and to get rid of the IO-blocking-UI problem (which I agree is a problem, and might be one of my biggest criticisms of Emacs). Am I missing something?

admax88qqq 3y ago
I honestly don't think IO-blocking-UI is such a big issue. And if you try to solve it using workers you introduce an annoying programming paradigm of async/await and IPC. Copying data over IPC can be slow, and having to set up IPC to share the data you need to run in a worker is also annoying. The great thing about the single threaded shared memory model of elisp is that it's a lot easier to code against. And yeah sometimes someone blocks the UI doing synchronous I/O, but that comes at the benefit of making it really easy for people to write addons that do all sorts of things. A lot of the I/O blocking UI problems could be alleviated by just moving to async I/O primitives without incurring the runtime and developer experience problems of a multi process architecture
- danShumway 3y ago
  Hrm. I don't know if I agree with this or not. Your last sentence is 100% spot on. But at the same time, I've used Emacs as a window manager before, and the reason I stopped was because of IO blocking the UI. I could not handle having a process bug out and having it freeze my entire window manager, and it happened frequently. I don't want to dismiss the argument; maybe it's just that Emacs packages are bad at avoiding that behavior? But I'm not sure that async I/O primitives are enough for a text editor, even though I would generally agree with you. On the subject of that last sentence: > A lot of the I/O blocking UI problems could be alleviated by just moving to async I/O primitives without incurring the runtime and developer experience problems of a multi process architecture This sounds like an advertisement for Javascript to me? This is one of the reasons I think why NodeJS became so popular when it was first introduced, literally because it was single-threaded with good async I/O primitives (or good enough, this was before Promises were in the language), and that led to huge performance improvements over other server implementations that prioritized workers. So while I still don't like the kitchen sink approach, I'm still left feeling like a lot of the problems and solutions being proposed here are kind of things that would be addressed by using Deno in Emacs? At least, I'm seeing the appeal. Single-threaded memory pool to help make developer experience better and to improve performance, coupled with decent async I/O primitives -- that's Javascript, that's one of the things the language is sort of good at. You have workers for larger tasks, and that's definitely handy, but most of your programming is happening in a single-threaded event loop using promises. If I looked at this sentence in isolation, I would think that you were arguing in favor of adding Deno.

dleslie 3y ago

If Emacs moved away from Lisp I would simply stop using Emacs. It's a key factor in why I use Emacs instead of NeoVim, or VSCode.