3 ms·

This is putting a lot of blame on the user, who likely has no clue how emacs i/o behaves. > if you're experiencing I/O hangs, it's either misconfiguration or b

by chrsig 4y ago

This is putting a lot of blame on the user, who likely has no clue how emacs i/o behaves. > if you're experiencing I/O hangs, it's either misconfiguration or bad code in a package that you loaded I mean...yes. That's the issue. The issue is that it's possible to have i/o hangs caused by misconfiguration or elisp packages. The solution isn't to tell the user to do something different, it's to make it so that elisp execution can't cause i/o hangs. edit: to a be a bit more precise with language: "i/o hang" should be interpreted as "making the UI unresponsive or preventing other tasks from completing".

medstrom 4y ago
How would you make it impossible to make the UI unresponsive? Given that lots of packages directly want to do stuff with UI?
- chrsig 4y ago
  I'm not going to have a great answer for how, especially in something with as much legacy as emacs. And I certainly don't mean to imply that solving the problem is easy (or possible for 100% of cases), or otherwise detract from efforts that the community has made. My intent was to highlight on what a good solution looks like from a user perspective. Off the top of my head, in an incredibly hand-wavey fashion: A quick win would be to set a timeout on every single i/o action, with the default timeout being quite low. That doesn't remove the problem, but it'd probably be a good start towards easing the user pain. Bringing an indefinitely long hang down to 1s is a win. For a total solution, I'd consider looking into implementing a concurrency model with a preemptive scheduler, probably using erlang as inspiration. have updates to the ui becoming a message sent to the ui inbox, and the routine for rendering the ui just reading from the inbox and applying the given command. This is without thought to how to actually implement that, and what implications it would have on legacy elisp, or how legacy elisp could be brought into a CSP world without breakage. So just some armchair architecting on a day off for a project I've never worked on :)
jrockway 4y ago
> This is putting a lot of blame on the user I think you're missing the point. Emacs already contains all the support necessary to make LSP not lock up the UI, LSP simply doesn't use it. So if you say "LSP is a great use case for multi-threaded Emacs", that's not correct. The problem with LSP specifically is that Emacs doesn't really know what the language server is going to do, and if it let you update the text while the language server was also updating the text, it would have to have some way to merge the changes that you made while the language server was busy. There would need to be some spec for that, or more likely, another trip to the language server to figure out what to do. You could, of course, edit the text while that second trip was happening, and this algorithm never converges to a finished state. So, it locks the UI so you can't make any edits until the text from the language server comes back. That's the easy way out, but at least it results in an algorithm that terminates. The way to fix this is to figure out where the time is being spent. If it's on JSON marshaling/unmarshaling, speed that up. If it's because the language server is slow, speed that up. The only compromise right now would be to let you edit buffers in a different project while the language server is processing something. I don't think anyone wants to do that; "I don't want LSP to lock up Emacs" really means "I want my language server to perform all operations instantly." So get out that profiler for your language server, I think.
- bitwize 4y ago
  > I think you're missing the point. I don't. "The only thing that matters in software is the experience of the user." The Emacs user experience is full of I/O hangs; the VSCode experience is not. This is a problem that needs to be solved if Emacs is ever to have a significant installed base again.
  - armitron 4y ago
    > The Emacs user experience is full of I/O hangs I can't remember the last time I had an I/O hang in Emacs. I'm also fairly active in the mailing list and various forums, I/O hangs are not really what's being discussed day to day. So I have to ask, are you projecting or what makes you say something like that?

by chrsig 4y ago

medstrom 4y ago

How would you make it impossible to make the UI unresponsive? Given that lots of packages directly want to do stuff with UI?

chrsig 4y ago
I'm not going to have a great answer for how, especially in something with as much legacy as emacs. And I certainly don't mean to imply that solving the problem is easy (or possible for 100% of cases), or otherwise detract from efforts that the community has made. My intent was to highlight on what a good solution looks like from a user perspective. Off the top of my head, in an incredibly hand-wavey fashion: A quick win would be to set a timeout on every single i/o action, with the default timeout being quite low. That doesn't remove the problem, but it'd probably be a good start towards easing the user pain. Bringing an indefinitely long hang down to 1s is a win. For a total solution, I'd consider looking into implementing a concurrency model with a preemptive scheduler, probably using erlang as inspiration. have updates to the ui becoming a message sent to the ui inbox, and the routine for rendering the ui just reading from the inbox and applying the given command. This is without thought to how to actually implement that, and what implications it would have on legacy elisp, or how legacy elisp could be brought into a CSP world without breakage. So just some armchair architecting on a day off for a project I've never worked on :)

jrockway 4y ago

> This is putting a lot of blame on the user I think you're missing the point. Emacs already contains all the support necessary to make LSP not lock up the UI, LSP simply doesn't use it. So if you say "LSP is a great use case for multi-threaded Emacs", that's not correct. The problem with LSP specifically is that Emacs doesn't really know what the language server is going to do, and if it let you update the text while the language server was also updating the text, it would have to have some way to merge the changes that you made while the language server was busy. There would need to be some spec for that, or more likely, another trip to the language server to figure out what to do. You could, of course, edit the text while that second trip was happening, and this algorithm never converges to a finished state. So, it locks the UI so you can't make any edits until the text from the language server comes back. That's the easy way out, but at least it results in an algorithm that terminates. The way to fix this is to figure out where the time is being spent. If it's on JSON marshaling/unmarshaling, speed that up. If it's because the language server is slow, speed that up. The only compromise right now would be to let you edit buffers in a different project while the language server is processing something. I don't think anyone wants to do that; "I don't want LSP to lock up Emacs" really means "I want my language server to perform all operations instantly." So get out that profiler for your language server, I think.

bitwize 4y ago
> I think you're missing the point. I don't. "The only thing that matters in software is the experience of the user." The Emacs user experience is full of I/O hangs; the VSCode experience is not. This is a problem that needs to be solved if Emacs is ever to have a significant installed base again.
- armitron 4y ago
  > The Emacs user experience is full of I/O hangs I can't remember the last time I had an I/O hang in Emacs. I'm also fairly active in the mailing list and various forums, I/O hangs are not really what's being discussed day to day. So I have to ask, are you projecting or what makes you say something like that?