VS Code remains responsive, but it's difficult to get the reformatted text on to disk. 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. 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. 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.Įmacs behaves in a different but still incorrect way. 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). I cloned kubernetes/kubernetes, opened a random file, added fmt.Println("hello") at the wrong indentation level somewhere, and pressed save. 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.įor the purposes of this argument I went and installed VSCode. The only compromise right now would be to let you edit buffers in a different project while the language server is processing something. If it's because the language server is slow, speed that up. If it's on JSON marshaling/unmarshaling, speed that up. The way to fix this is to figure out where the time is being spent. That's the easy way out, but at least it results in an algorithm that terminates. So, it locks the UI so you can't make any edits until the text from the language server comes back. You could, of course, edit the text while that second trip was happening, and this algorithm never converges to a finished state. There would need to be some spec for that, or more likely, another trip to the language server to figure out what to do. 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. So if you say "LSP is a great use case for multi-threaded Emacs", that's not correct. Emacs already contains all the support necessary to make LSP not lock up the UI, LSP simply doesn't use it. > This is putting a lot of blame on the user Assuming moderate effort, this will come with experience and time spent using Emacs. Given the (enormous amount / ever-increasing number) of Emacs Lisp packages out there, a lot of them being substandard, being able to make these sort of qualitative calls (and also increasingly dive into Emacs internals) will pay off. LSP Mode is written by volunteers on Github, and the code is nowhere near as good. I can definitely say that if you're experiencing I/O hangs, it's either misconfiguration or bad code in a package that you loaded.įinally for LSP, I always recommend Eglot over LSP Mode, as Eglot is written by an Emacs contributor that has deep knowledge of Emacs and Emacs Lisp. It is therefore up to you, to use the proper package (or not use the wrong one) / configure Emacs in such a way, so that this sort of issue is avoided. However, not everything that runs on Emacs is taking advantage of that functionality. Emacs already supports asynchronous I/O and has sentinels for exactly that. I'm willing to dive the subject deeper beacuse Emacs and Lisp had thrown a charm on me.That multi-threading will solve this issue, is a common misconception. Now i think the meaning of "install lsp-mode on top of gdscript-mode" is: 1. If I start the engine from command prompt as usual, it shoots lots of errors, telling me the resource is not initilized and creates empty copy of edited script but with strange name: ".#NameOfTheSript.gd".Īnyway it started to work just fine for Me, even if Emacs with lsp-mode enabled seems to be a little bit slower. However Godot must be started directly from emasc. I suppose lsp-server is some kind of an object, not a library as I thougt, and must be somehow initialized to the memory. Im to nooby as a programmer to understand why is that. Part of the problem was that, I supposed, there is no need to start up the engine to use the lsp-server. (I have no idea how to change the port on the emacs-lsp-server). It confirms what I deduced from lsp-server error I found in emacs day after I asked a question.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |