4 ms·

> 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

> 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?
  - appletrotter 4y ago
    As a third party in this conversation, and someone who uses emacs daily - I/O hangs seem to be something that is a pretty frequent issue for users. My emacs likes to crash sometimes, usually a few times a week. Hopefully I’ll be able to take some time to bisect my config and see what’s going on. Looks like a memory leak.
    - Kaze404 4y ago
      To add to this, my Emacs never crashes but at least once a week I'll run an innocent command (sometimes just opening magit) and it will become unresponsive indefinitely, with the only way of closing it being sending a kill command from the terminal.
      - gjadi 4y ago
        If your emacs freezes, you can often recover it by sending the USR2 signal. When it receives this signal, Emacs will drop in the debugger.
  - anthk 4y ago
    Sadly it's common with Gnus.
hatmatrix 4y ago
If this is the core of the problem, how does VSCode solve it? It seems users report less latency issues with VSCode - have they figured out how to handle the two-way communication better?
- jrockway 4y ago
  For the purposes of this argument I went and installed VSCode. I cloned kubernetes/kubernetes, opened a random file, added fmt.Println("hello") at the wrong indentation level somewhere, and pressed save. While gopls is initializing, it pops up a thing saying "waiting for code actions from the language server" (or similar; it wants the language server to "gofmt" the file). After that completes, the line I wrote appears at the right indentation level in the editor, but what's on disk is `fmt.Println("h` at the wrong indentation level. Emacs behaves in a different but still incorrect way. It writes the entire fmt.Println statement at the wrong indentation level, locks up for a while, and decides that there was no formatting to do. VS Code will be fast after a while, but Emacs never gets fast; every reformat request locks up the UI for several seconds and doesn't actually reformat. VS Code remains responsive, but it's difficult to get the reformatted text on to disk. (Sometimes it does it, though.) My main conclusion is that you're screwed if you have to work on k8s day to day. But on a more serious note, this isn't really an issue that can be solved with a UX tweak; the class of problem is "the optimal algorithm for providing instant hints on a codebase that is 214k lines hasn't been discovered yet". Yes, editors can let you mutate the text while it's working on something in the background; and if you turn of language server support that's fine. The key problem is merging your edits with its set of assumptions, and that's what's going to be slow.

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?
- appletrotter 4y ago
  As a third party in this conversation, and someone who uses emacs daily - I/O hangs seem to be something that is a pretty frequent issue for users. My emacs likes to crash sometimes, usually a few times a week. Hopefully I’ll be able to take some time to bisect my config and see what’s going on. Looks like a memory leak.
  - Kaze404 4y ago
    To add to this, my Emacs never crashes but at least once a week I'll run an innocent command (sometimes just opening magit) and it will become unresponsive indefinitely, with the only way of closing it being sending a kill command from the terminal.
    - gjadi 4y ago
      If your emacs freezes, you can often recover it by sending the USR2 signal. When it receives this signal, Emacs will drop in the debugger.
- anthk 4y ago
  Sadly it's common with Gnus.

hatmatrix 4y ago

If this is the core of the problem, how does VSCode solve it? It seems users report less latency issues with VSCode - have they figured out how to handle the two-way communication better?

jrockway 4y ago
For the purposes of this argument I went and installed VSCode. I cloned kubernetes/kubernetes, opened a random file, added fmt.Println("hello") at the wrong indentation level somewhere, and pressed save. While gopls is initializing, it pops up a thing saying "waiting for code actions from the language server" (or similar; it wants the language server to "gofmt" the file). After that completes, the line I wrote appears at the right indentation level in the editor, but what's on disk is `fmt.Println("h` at the wrong indentation level. Emacs behaves in a different but still incorrect way. It writes the entire fmt.Println statement at the wrong indentation level, locks up for a while, and decides that there was no formatting to do. VS Code will be fast after a while, but Emacs never gets fast; every reformat request locks up the UI for several seconds and doesn't actually reformat. VS Code remains responsive, but it's difficult to get the reformatted text on to disk. (Sometimes it does it, though.) My main conclusion is that you're screwed if you have to work on k8s day to day. But on a more serious note, this isn't really an issue that can be solved with a UX tweak; the class of problem is "the optimal algorithm for providing instant hints on a codebase that is 214k lines hasn't been discovered yet". Yes, editors can let you mutate the text while it's working on something in the background; and if you turn of language server support that's fine. The key problem is merging your edits with its set of assumptions, and that's what's going to be slow.