一个简单的json文件不应该是障碍，就好像要生成tag文件一样，总是要有一些配置或者命令来驱动。原理上肯定lsp的索引是最准确的，就看性能能不能满足。我之前写驱动，用的ccls用来还行，也不需要特别的配置（我用了一个空的json文件就开干了）。据说clangd进步很大，但一直没使用起来。
我也来说说，上面说qt的代码比kernal还大，我确实用clangd.索引过qt。bear生成的json.，平时也就用来浏览代码。补全跳转都不错的，一点不延迟。也索引过libreoffice的源码，性能也非常好。libreoffice我统计过，大概源文件有七八千个左右吧。
1 个赞
我大概 2 年前试图在 linux kernel 上用 lsp 的一个主要障碍是，当时 kernel 没法用 clang 编译，虽然有各种文章介绍怎么 workaround，但是实在太麻烦了。而且对于 kernel 这种有些年头的 C 项目，里面的头文件依赖一团糟，有时一个简单的头文件修改，搞不好会触发整个 kernel 的重新编译。既然当时 cscope 基本可以开箱即用的解决我所需要的各种查找和跳转功能，lsp 也没法带来更多的改善，所以就不折腾 lsp 了。不知道现在 lsp 在 kernel 上是个什么样子。
qt不需要用bear, 因为它用cmake
lsp一直都不需要用clang来编译的.
我当时用的lsp server是clangd，json文件是通过bear make生成的，clangd使用这个文件时会抱一堆gcc specific的flags它识别不了。当时主要就是在折腾这些问题。
你是什么行业？我想先初步调查，再决定是否开发新插件。
我以前给柯达开发图像处理软件时使用过cscope浏览C++,对其印象很好。但是我不想自己开发的插件绑定在一个很少用户的软件上。如果emacs+cscope的用户没有超过一百个人的话，我就不想浪费精力了。
另外要求emacs 27+是否可行？
嵌入式的，现实生活中用 emacs 都没见到 第二个，那肯定不会超过 100 人啊 
我不太了解cscope，仅从cpp用户的角度。如果代码量不是很大是很值得的，应该有很多人不喜欢依赖太多的东西。写cpp写久了不怎么依赖智能补全啥的，最看重的其实就是浏览代码的体验，si和understand 做的不错，就是太笨重而且受限太多，如果cscope能满足项目跳转的需求，那真是一包足矣。
但如果实现代码比较复杂的话，对维护者和使用者的要求变高了，大家也许也不太愿意接触了，可能就大项目用tag系统，虽然不太精准也能用，小项目用lsp。
我也是嵌入式，大的工程用SI浏览，但写的时候还是用emacs舒服，补全倒不是很依赖。
现在citre 基本能用吧，一些不能解决的问题 还是 出现在 ctags 上。我现在全程都是 emacs,每天第一个打开的软件就是 Emacs
在用counsel-etags，citre还没试过，抽空会试下。 对于ctags，好像更新tags文件的话，只能append添加（会重复），或者完全重新生成tags文件是么