lsp-bridge -- 速度最快的语法补全插件

更新:刚我快速配置试了下eglot(它简单,马上就能用,lsp-mode懒得试了,虽然有个config又大又老),没有问题,看来是lsp-bridge在处理namespace返回信息哪里有bug吧,也可能是我在用Emacs 30问题?

版本信息:

  • Emacs: emacs-plus@30
  • clangd: Apple clangd version 16.0.0 (clang-1600.0.26.4), Platform: x86_64-apple-darwin24.1.0
  • lsp-bridge: commit: acebc3, 20 Dec 2024

没有,enable log的变量值是nil。

我试了试其它的稍大点的库,像OpenCV,补全namespace下的内容 如cv::Ma后都很慢,您这边没有这个问题吗?说不上来是什么问题(我已经试了各种clangd参数,感觉不是clangd的问题)。现在我有点想确定的是这是共性问题还是我的个人问题。

请问别的坛友们编C++有这种问题吗? 我还是有点觉得如果是共性问题有点不真实,大家真编C++除了标准库总会用点别的大库吧(难道说C++已经衰落如斯了么,没什么人用也就没发现。。。)

下面我用的OpenCV的简单例子,应该量也不会很大:

#include <opencv2/core.hpp>
#include <opencv2/imgcodecs.hpp>
#include <opencv2/highgui.hpp>

#include <iostream>

int main()
{
    std::string image_path = cv::samples::findFile("../resources/cat.jpeg");
	cv::Mat img = cv::imread(image_path, cv::IMREAD_COLOR);

    if(img.empty())
    {
        std::cout << "Could not read the image: " << image_path << std::endl;
        return 1;
    }

	cv::imshow("Display window", img);
    int k = cv::waitKey(0); // Wait for a keystroke in the window

    if(k == 's')
    {
		cv::imwrite("cat.png", img);
    }

    return 0;
}

cmake文件:

cmake_minimum_required(VERSION 3.5.0)

# cxx version
set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED TRUE)

# compiler
set(CMAKE_C_COMPILER "/usr/bin/clang")
set(CMAKE_CXX_COMPILER "/usr/bin/clang++")

# clangd support
set(CMAKE_EXPORT_COMPILE_COMMANDS ON)

# project
project(test_eigen VERSION 0.1.0 LANGUAGES C CXX)

include_directories(/usr/local/include/opencv4)
include_directories(${PROJECT_SOURCE_DIR}/include)

link_libraries(/usr/local/lib/libopencv_core.dylib)
link_libraries(/usr/local/lib/libopencv_imgcodecs.dylib)
link_libraries(/usr/local/lib/libopencv_highgui.dylib)

add_executable(a.out main.cpp)

算了,年底大家都挺忙的,看群里、论坛大家都不怎么有空上了,等过了年关再说哇 15

asciicast

挻快的呀,虽然我用的 lsp-mode + plist + lsp-booster (逃 :rofl:

谢谢!我也是试了下eglot,按complete-symbol也是秒出,可能是lsp-bridge哪里有点问题吧。

我在Msys2的UCRT环境中编辑python文件,刚开始使用时,lsp-bridge的补全正常,工作一段时间后,补全的信息全是乱码,请教一下定位这个问题的思路。

最近使用lsp-bridge有个python 补全疑问,from形式的导入好像无法补全?比如

from _collections import OrderedDict 从头到尾都没有补全

用的lsp是pyright,其它python代码补全是正常的 想请问一下 是不是哪里需要做配置,还是python环境有问题?

用basedpyright吧

应该是emacs编码没配置好

原来 basedpyright 的作者和 pyright 的作者还有争执 :rofl:

改成BASEDPYRIGHT了, 还是老样子。不过有新发现 不带’_‘的from collections import OrderedDict就可以补全。 并且在同样环境里两种写法都能正常运行

问了一下GPT,讲了一大通,感觉有用的是 “

_collections 是内部实现模块

  • _collections 是 Python 的内部模块,名字以 _ 开头表明它不是公共 API,而是为实现 collections 模块提供底层支持。
  • 一般不建议直接使用 _collections,因为:
    • 它可能随 Python 版本变化而改变或被移除。
    • 它的接口可能未经过文档说明。 "

先这么用着吧,主打一个不甚了了~

lsp-bridge-find-references 为啥不把定义也一起show出来呢,查找引用后如果想重命名该变量,还需要单独把定义找到再修改。

lsp-bridge 只是 LSP Client, 也许你需要 Peek [简体中文版] · manateelazycat/lsp-bridge Wiki · GitHub

我发现这个github的url真是有毛病。下面这个链接实际上根本打不开

https://github.com/manateelazycat/lsp-bridge/wiki/Peek-[简体中文版]

当然假如你已经打开了我上面的网址,实际复制浏览器地址栏的时候会复制为:

https://github.com/manateelazycat/lsp-bridge/wiki/Peek-%5B%E7%AE%80%E4%BD%93%E4%B8%AD%E6%96%87%E7%89%88%5D

有没有大佬看看哪出问题了,同样包含中文的这个地址,就能够顺利打开。

https://github.com/manateelazycat/lsp-bridge/wiki/优化-Python-性能

用vimium的用户表示非常怪异,复制好的url,却打不开链接。可以尝试复制猫大的那个peek的链接,再打开。

方括号,这样可以:

https://github.com/manateelazycat/lsp-bridge/wiki/Peek-%5b简体中文版%5d

最近不知道怎么突然 lsp-bridge 就不能用了。一看是 watchdog 模块找不到。

求问大佬,你这 Nix 语言最后的这句

ln -s ${python}/bin/python $out/bin/python-for-lsp-bridge

是什么意思?

我运行后怎么是在当前文件夹下的 result 中创建一个链接。这样的话,lsp-bridge 是不是找不到。

手动将这个链接复制到 /usr/bin 就行了。 这个还真是挺方便的,谢谢分享。

lsp bridge 不能补全路径吗? 我系统中有一个名为 /win_Desktop 的路径, 貌似它没有补全提示.

要在字符串中才可以

感谢~

1 个赞

你是用的 nix build 吧?

pkgs.runCommand 打包 package 的时候, $out 代表 package 的最终目录。这里的 ${python} 代表在 let ... in 里打包出来的 python 环境目录。

由于要使用打包的 python 环境里的 python 指令,为了避免 PATH 里的名称冲突,所以这里打包一个只包含名称为 python-for-lsp-bridge 这个指向 python 环境里的 python 指令的软链接。

如果你用 nix build 构建一个 package,那么会在当前目录生成一个指向目标 package 的软链接。

如果你用的 NixOS 或者 home-manager,把这个 package 的构建代码添加到对应配置文件里,那么 $out/bin/ 里的可执行文件会被自动添加到 PATH 环境变量里。

如果你都没有使用,也可以通过 nix profile install 来指令式地把 package 安装到 profile 里。

另外一提: nixpkgs 官方仓库 24.11 对 lsp-bridge 的集成已经更新到 2024-10-07 了(截至 2025-01-21,unstable 分支里更新的版本是 2025-01-11),如果知道在 nix 下怎么使用 emacsWithPackages ,又不追求用最新版本的 lsp-bridge 的话,可以使用 emacsPackages.lsp-bridge 而不必关心如何打包 lsp-bridge 的 python 环境。