5 ms·

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

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.
  - samus 3y ago
    Adding a new language still doesn't solve the blocking problems with the current extensions. It still seems way less complicated to just patch the extensions that are not behaving well. If their maintainers don't want to cooperate, there is always the possibility to fork these extensions, but that's also way easier than writing these from scratch or treating them in Typescript.
    - danShumway 3y ago
taeric 3y ago
I'm still not entirely clear that most people understand the problems that well. The way you would hear it on most forums, emacs blocks whenever you do anything that takes time. Nevermind compilation mode being a thing basically forever. So, yes, you can block the UI thread. There have been ways to not do that basically forever. I welcome better ways to manage this, but there will always be some way to do code on the UI thread, such that it will always be possible to somewhat block things. The alternative is to make all code preemptive, it seems. And that just begs for race conditions on the shared mutable state that is the editor.
- danShumway 3y ago
  So this is a complaint I do have. But in fairness, I do worry a little that I've used Emacs for so long as my primary text editor that I've lost perspective of what the failure rates are for other text editors. I remember Atom being absolutely terrible about this, and thinking that Emacs was basically as good if not significantly better at not blocking the UI whenever it needed to think. The problem is I had to use Atom for a while seriously before I understood how often it failed for me. If you're just trying out a text editor to see if it's comfortable, you don't see these failure modes as clearly. So I've tried VSCode before, but I don't know if it's better or worse at avoiding hanging the UI, because I don't use it constantly all day long with a ton of packages installed. If I had to make a list of all the times I get frustrated at Emacs, a long operation that has nothing to do with the UI blocking everything is pretty high on the list, that is a regular complaint that I have. I feel comfortable saying that I wish Emacs packages would get better at this, and maybe there are ways to improve it within Emacs. But I guess truthfully for all I know VS Code could have the same problem but even worse. I agree that making code preemptive is probably not a good idea.
- oefrha 3y ago
  > The way you would hear it on most forums, emacs blocks whenever you do anything that takes time. Nevermind compilation mode being a thing basically forever. Sure, it’s possible to write code that doesn’t block the UI, but it’s very difficult in Emacs and just about every built-in functionality is an offender. This includes network operations, which can block forever. You’d be laughed out of the room if you implemented a text editor today that can lock up completely and indefinitely with M-x package-list-packages.
jlarocco 3y ago
> Genuine question, not trying to be snarky: isn't JS a great way to address most of those concerns that you list? I genuinely don't think it is - Javascript is just a language. Why not implement Async I/O and WebWorkers APIs in Elisp? Why complicate things with an entirely new language? And with Elisp native compiled on most platforms, it seems doubtful WebAsm is going to make a noticeable difference in performance.
- ASalazarMX 3y ago
  Fair point, but have you considered the joy of tarnishing nice things with JavaScript? Corrupting the venerable Emacs would be a great achievement.
- da39a3ee 3y ago
  I'm assuming this change will allow plugins to be written that expose a web UI. That would be huge for Emacs.
  - hulitu 3y ago
    > That would be huge for Emacs. Yes, it will change its name from Emacs (8 megabits and constantly swapping) to Etacs (8 terabits and constantly swapping). /s
quadrifoliate 3y ago
> Genuine question, not trying to be snarky: isn't JS a great way to address most of those concerns that you list? Backward compatibility is the elephant in the room about some of this stuff that most Emacs users absolutely take for granted. I personally have about 20 years worth of Emacs Lisp config files; and others have more decades worth. They largely have continued working for all those years. I hope that whoever is working on this fancy Deno/Javascript stuff realizes this, and actually talks to some Emacs users if they want any kind of actual adoption. When I look at the README, I'm seeing one mention of "Warning: This feature is currently unmaintained", and another of "Note: This feature is currently outdated and been disabled. However there is this to bring it back." This...does not inspire confidence in the minds of long-term Emacs users. Now, maybe I'm being curmudgeonly and unfair. Like the README says, I do want Emacs to be a an editor for the next 40+ years. I just doubt it's going to get there without Emacs Lisp.

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.
- samus 3y ago
  Adding a new language still doesn't solve the blocking problems with the current extensions. It still seems way less complicated to just patch the extensions that are not behaving well. If their maintainers don't want to cooperate, there is always the possibility to fork these extensions, but that's also way easier than writing these from scratch or treating them in Typescript.
  - danShumway 3y ago

taeric 3y ago

I'm still not entirely clear that most people understand the problems that well. The way you would hear it on most forums, emacs blocks whenever you do anything that takes time. Nevermind compilation mode being a thing basically forever. So, yes, you can block the UI thread. There have been ways to not do that basically forever. I welcome better ways to manage this, but there will always be some way to do code on the UI thread, such that it will always be possible to somewhat block things. The alternative is to make all code preemptive, it seems. And that just begs for race conditions on the shared mutable state that is the editor.

danShumway 3y ago
So this is a complaint I do have. But in fairness, I do worry a little that I've used Emacs for so long as my primary text editor that I've lost perspective of what the failure rates are for other text editors. I remember Atom being absolutely terrible about this, and thinking that Emacs was basically as good if not significantly better at not blocking the UI whenever it needed to think. The problem is I had to use Atom for a while seriously before I understood how often it failed for me. If you're just trying out a text editor to see if it's comfortable, you don't see these failure modes as clearly. So I've tried VSCode before, but I don't know if it's better or worse at avoiding hanging the UI, because I don't use it constantly all day long with a ton of packages installed. If I had to make a list of all the times I get frustrated at Emacs, a long operation that has nothing to do with the UI blocking everything is pretty high on the list, that is a regular complaint that I have. I feel comfortable saying that I wish Emacs packages would get better at this, and maybe there are ways to improve it within Emacs. But I guess truthfully for all I know VS Code could have the same problem but even worse. I agree that making code preemptive is probably not a good idea.
oefrha 3y ago
> The way you would hear it on most forums, emacs blocks whenever you do anything that takes time. Nevermind compilation mode being a thing basically forever. Sure, it’s possible to write code that doesn’t block the UI, but it’s very difficult in Emacs and just about every built-in functionality is an offender. This includes network operations, which can block forever. You’d be laughed out of the room if you implemented a text editor today that can lock up completely and indefinitely with M-x package-list-packages.

jlarocco 3y ago

> Genuine question, not trying to be snarky: isn't JS a great way to address most of those concerns that you list? I genuinely don't think it is - Javascript is just a language. Why not implement Async I/O and WebWorkers APIs in Elisp? Why complicate things with an entirely new language? And with Elisp native compiled on most platforms, it seems doubtful WebAsm is going to make a noticeable difference in performance.

ASalazarMX 3y ago
Fair point, but have you considered the joy of tarnishing nice things with JavaScript? Corrupting the venerable Emacs would be a great achievement.
da39a3ee 3y ago
I'm assuming this change will allow plugins to be written that expose a web UI. That would be huge for Emacs.
- hulitu 3y ago
  > That would be huge for Emacs. Yes, it will change its name from Emacs (8 megabits and constantly swapping) to Etacs (8 terabits and constantly swapping). /s

quadrifoliate 3y ago

> Genuine question, not trying to be snarky: isn't JS a great way to address most of those concerns that you list? Backward compatibility is the elephant in the room about some of this stuff that most Emacs users absolutely take for granted. I personally have about 20 years worth of Emacs Lisp config files; and others have more decades worth. They largely have continued working for all those years. I hope that whoever is working on this fancy Deno/Javascript stuff realizes this, and actually talks to some Emacs users if they want any kind of actual adoption. When I look at the README, I'm seeing one mention of "Warning: This feature is currently unmaintained", and another of "Note: This feature is currently outdated and been disabled. However there is this to bring it back." This...does not inspire confidence in the minds of long-term Emacs users. Now, maybe I'm being curmudgeonly and unfair. Like the README says, I do want Emacs to be a an editor for the next 40+ years. I just doubt it's going to get there without Emacs Lisp.