In remote edition, pyright stuck while clangd worked fine.

[PannenetsF]

LSP-bridge works perfectly when editing local files (C++ and Python), but things are different for remote editing.
Cpp still works, but Python completions are too slow to use. The candidates are always behind schedule.

In this screenshot, the candidate was working on completing the "o" in "os", while I have typed the "os.path.abs" I have tested over different python lsp servers and it held for every server.

Could anyone give suggestions on that? 🤔 Thanks

[manateelazycat]

Please use emacs -Q for compare test, I guess your other plugin make your emacs slow, not lsp-bridge

[PannenetsF]

@manateelazycat Thanks for the response. First, lsp-bridge is fast and robust enough, as the clangd works amazingly good in remote dev. I have double-checked with emacs -Q with minimal config for python. The issue remains, thus it is pyright-related.
I just wonder if anyone could use pyright or other lsp server correctly. Do you have any suggestions?

(setq package-enable-at-startup nil)

(unless (package-installed-p 'use-package)
  (package-refresh-contents)
  (package-install 'use-package))

(require 'use-package)

(use-package yasnippet
  :ensure t)
(use-package markdown-mode
  :ensure t)

(use-package python)

(require 'yasnippet)
(require 'markdown-mode)

(yas-global-mode 1)

(add-to-list 'load-path "./lsp-bridge")

(require 'lsp-bridge)
(global-lsp-bridge-mode)

(setq lsp-bridge-python-lsp-server 'pylsp)
(setq lsp-bridge-python-command "python")

[manateelazycat]

use basedpyright lsp server，it will much faster

[PannenetsF]

The completion still did not work. I noticed all the function info (in the minibuf) worked well among different servers. Do you think it is a rendering issue or lsp sending mistaken message? I would like to help on this issue and I think it might happen to other users.

The lsp_bridge.py should work well according to its log.

--- [16:41:08.364088] Send textDocument/completion request (22735) to 'basedpyright' for project run.py

--- [16:41:08.364183] Send workspace/symbol request (27920) to 'basedpyright' for project run.py

--- [16:41:08.398503] Recv textDocument/completion response (22735) from 'basedpyright' for project run.py

[manateelazycat]

Please add some log at lsp-bridge-completion--record-items, check whether something wrong with Emacs side?

[PannenetsF]

Thanks for the debug tips! I have determined the source of the issue based on that.

The second entry (time of change_cursor) of last_change often changes. Thus, lsp-bridge skips the handling of the completion response. My solution is to set Completion.cancel_on_change = True. After that, lsp-bridge works as fast as local dev!

I wonder the design purpose of the Completion.cancel_on_change. When someone taps a sequence of code, completion occurs everywhere, and thus Completion.cancel_on_change should be true. Is that right? @manateelazycat

https://github.com/manateelazycat/lsp-bridge/blob/master/core/handler/__init__.py

if request_id != self.latest_request_id: ...
if self.cancel_on_change and self.last_change != self.file_action.last_change: ...

[manateelazycat]

Completion.cancel_on_change default is True, aren't you?

[PannenetsF]

oops, that's a typo. I changed it to false.

[manateelazycat]

oops, that's a typo. I changed it to false.

Change it to False, then problem solved?

[PannenetsF]

Yes, the slow completion disappeared. I believe the request filtering is the source.

[manateelazycat]

It's strange