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

Emacs-general
3793

更新：刚我快速配置试了下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)
3794

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

3795

asciicast

挻快的呀，虽然我用的 lsp-mode + plist + lsp-booster （逃 :rofl: ）

3796

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

3798

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

3799

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

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

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

3800

用basedpyright吧

3801

应该是emacs编码没配置好

3802

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

3803

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

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

_collections 是内部实现模块

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

先这么用着吧，主打一个不甚了了～

3804

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

image
image1493×528 62.9 KB

3805

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

3806

我发现这个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的链接，再打开。

3807

方括号，这样可以：

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

3808

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

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

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

是什么意思？

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

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

3809

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

Snipaste_2025-01-20_15-48-01
Snipaste_2025-01-20_15-48-011310×644 32.2 KB

3810

要在字符串中才可以

3811

感谢~

1 个赞
3812

你是用的 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 环境。