建议 @yyoncho 来看看这个贴
这个不好讲，有些用 lisp 实现很方便的，但和一般语言差别有些大。
印象中, lsp-mode的issue里有人提过用动态模块实现lsp的想法.
嗯嗯，我关掉了lsp-ui; 不知道是不是最近有更新，感觉会在底部提示很长的函数使用，我其实不需要，但不能关掉，很抱歉还没有认真读它的readme。
其实我用lsp很多，在python，在c++，也用dap和它配合，感觉还不错；在python上提示，比ananconda-mode要全面。
目前市面上各种服务和复杂协议几乎都是其他语言实现的, 整体经验和库肯定要比lisp成熟很多, 从这方面来讲, 开发效果几乎可以肯定会超越lisp.
Most likely it wont. Dynamic modules are extremelly inefficient when there are elisp calls from rust also converting RUST datastructures to elisp datastructures should happen in the emacs thread - you cannot call elisp methods not being in emacs thread.
See [Discussion] json dynamic module · Issue #676 · emacs-lsp/lsp-mode · GitHub
IMO ATM the easiest way to achieve what OP is describing is to rework emacs core to allow memory allocation to happen on multiple threads(we were discussing that with Eli Zaretskii) and then implement async JSONRPC either in core or in dynamic module(assuming async support is exposed in dynamic modules). But recently. Eli Zaretskii optimized the json parsing with 30-40% and also the JSONRPC layer in lsp-mode was rewritten and optimized (~2times faster) I cannot find a scenario in which lsp-mode is not reponsive when using latest Emacs 27. Before that I was planning to open a discussion with Eli in emacs-devel but now I do not have performance report to backup my request - everything is fast enough.
4 个赞
If you do not like the import project dialog you may turn it off via setting lsp-auto-guess-root to t. Without the interactive root selection we were getting dozens of bug reports from users who have selected the wrong project root due to monorepos or similar.
Also, for all that do not like lsp-mode defaults - please share your opinion here: [poll] review some default settings · Issue #1226 · emacs-lsp/lsp-mode · GitHub . I am planning to move flycheck integration into separate package so lsp-ui will become optional component. Apparently, a lot of people do not like it so maybe it should not be enabled by default. Bear in mind that it is impossible to have defaults which everyone likes…
1 个赞
@yyoncho so, what do you think about the idea of using dynamic module to improve lsp-mode? I also think rust (or golang?) is a good choice.
文档显示可以加入ghelp支持😁我可以PR
I think that we could move process handling and building the json string in separate thread as described in first and then pass this to emacs to turn it into elisp datastructure. I believe that if someone is going to put effort into that it will be better to coordinate with emacs-devel and ask ubolonton for advice.
3 个赞
Ever since I move to emacs27 couple months ago, everything is indeed fast enough 
Thank you so much for your efforts man!
My only real problem is LSP + Tramp integration. I was using ccls over Tramp and the connection is always unstable and somtimes stuck in a loop. The LSP tramp connection documentation isn’t good enough to the point that I’m uncertain that my config is right. An issue had been created at emacs-ccls since, but I didn’t have too much time to debug around it as I changed my OS from Lubuntu to Manjaro KDE. All of a sudden the same config that (at least) worked on Lubuntu for ccls + tramp stops working at all in Manjaro. I don’t know if that’s my config’s problem or ccls’s problem or lsp-mode’s problem, still yet to find out 
Thank you for the feedback!
[quote=“MatthewZMD, post:42, topic:11238”] The LSP tramp connection documentation isn’t good enough to the point that I’m certain that my config is right. [/quote]
I the issue here is that lsp-mode tramp implementation requires internal lsp-mode knowledge. I think that the solution is to create a predefined recipes (I have started that in lsp-docker project). Are you aware that you have alternatives not involving tramp if you are using docker?
Thank you, I didn’t know this option exists. I will give it a try. I’m sure there are other people annoyed by it, maybe you could put a hint there when you ask project root about how it could be turned off, or even an option like “auto guess and never ask again”.
Whoops, I actually meant I’m uncertain that my config is correct. Forgot to put un there that changed the meaning of the sentence. So far, it worked on my previous Lubuntu machine but it doesn’t work on Manjaro. So I got no idea.
No, I usually don’t work with docker so I don’t know any performance benefits from LSP on docker 
You are right. IMO it’s best to have lsp-mode by default just integrate with Emacs builtin facilities (completion-at-point, eldoc, xref, flymake), and show user what optional packages are available in a welcome screen on first run.
Thank you for the feedback. In the core we have integration with imenu,xref,flymake,tramp,completion-at-point(not full becase we have company-lsp). We also have autodetection/autoconfiguration of few external packages like company-mode, lsp-ui, flycheck, yasnippet. About the dashboard - check [Feature] better lsp-describe-session · Issue #764 · emacs-lsp/lsp-mode · GitHub .
支持啊，一定要把clojure支持上:grinning:
想法很好！希望能比lsp早合进emacs。
What I thought is:
- The asynchronous thread in dynamic module sends the lsp request and recieves the reply.
- The asynchronous thread parses the reply message and prepares data to be used in elisp and notifies emacs with an event.
- Emacs recieves the event and call some function in elisp. The function fetches the prepared data in 2.
But I didn’t know that memory allocation is now allowed in the asynchronous thread in dynamic module. So we can’t prepare the data in 2. This is a big limit.
It works. But I think it is not a good design for an application like Emacs. Most modern applications(Google Chrome, Mozilla Firefox, MS VSCode …) have seperated the UI thread and the background threads to have good responsiveness. And they works well. Hope emacs will do this too.
- Allow memory allocation in asynchronous thread in dynamic module.
- Provide a better way for the background thread to commucate with the main thread.
- Or even create another isolated lisp interpreter in emacs with limited functions(like can’t access UI and user resources) but with full parallel threading support. A lisp interpreter for background threads only.
I think emacs will do many more cool things then.
1 个赞