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 个赞
Exactly. The only thing that is missing is someone to convince emacs-devel that this is needed and someone to implement it.
把耗时的步骤用 Rust 代替大概率会有 10x 以上的性能提升，这是我对 vim-clap 做的一个优化，Speed up the Python filtering using Rust · Issue #146 · liuchengxu/vim-clap · GitHub ，对 emacs 应该也是同样适用。找到其中的性能瓶颈，然后用 Rust 重写。
4 个赞
性能提升是毋庸置疑的，提升多少就要看场景了。好奇为啥不直接用 rg或者 ag，性能更好啊
只是 provider 的名字叫 grep, 实际上用的是 rg, 因为考虑到以后可能支持 ag, 所以起了一个比较通用的名字。
确实，稳定工作，没有莫名其妙的问题感觉最重要。eglot经常会在别的函数对buffer做一些编辑以后出错，看起来像是他自己维护的buffer状态corrupt了一样，比如报一些parse error，但实际上buffer里的代码没问题，这时候我就要重启eglot，挺烦的。关键是不好重现也不好报bug。
不如试试最新的 lsp-mode?
2 个赞
lsp-mode 和 eglot 在易用性和开箱即用上做的都挺糟糕的。
lsp-mode 太复杂，两个都有各种小bug，还不如不用。
试过最新的6.2.1，确实流畅了不少，不过我上一次用还是很久以前，但是比neovim的coc以及vscode来说都差一些（你的配置我也试过了）