kinono
1
Citre 此前只是一个 ctags 前端。经过重构，现在前后端分离了，前端提供用户界面，包括：
- citre-jump、citre-peek
- 自动补全、xref 和 imenu 的集成
后端现有两个：
global 后端适合以下情形使用：
- 需要查引用（可以和 tags 后端结合使用）
- 项目特别大，生成 tags 文件的时间不可接受（ctags 目前还不能增量更新，但 gtags 可以，因此只有第一次会耗时）
- 项目特别大，导致 tags 文件体积太大的（gtags 使用二进制 database，而且储存的信息没有 tags 文件那么全）
由于 GNU Global 自身的限制，global 后端提供的信息比 tags 后端少（比如不能显示一个符号是变量还是函数，是什么类型等等）。因此除了查引用以及在巨型项目中，global 并没有 ctags 好用。
global 后端不需要额外的 Emacs 配置，对照用户手册装好程序，配置一些环境变量后就可以使用了。欢迎大家试用。
26 个赞
编辑：
找到原因了，是我自己的 gtags.conf 中的 pygments-parser 没配置对，把 :ctagscom 改成自己电脑路径上对应的位置就可以了（ps：global 也需要用到 ctags 吗？我以为不需要的。。。）
想问下，之前没用过 global，我在按照手册运行的时候显示这个出来，正常吗？
$ gtags --explain
...
- File 'test.c' is handled as follows:
...
parser: |parser|
library: |/usr/lib/x86_64-linux-gnu/gtags/pygments-parser.so|
~~~~~~~~~~~~~~~~（这是我自己加的，我多了一行这个路径）
...
这个 pygments-parser.so 貌似是随着 global 一同安装的，要调用的话不应该是调用 pip install pygments 安装的相关库吗？
并且运行 global -x f 没反应，把 GTAGSLABEL 改成 native-pygments 的话倒是正常
$ export GTAGSLABEL=pygments
$ gtags --explain
...
- File 'test.c' is handled as follows:
suffix: |.c|
language: |C|
parser: |parser|
library: |/usr/lib/x86_64-linux-gnu/gtags/pygments-parser|
...
$ global -x main
# 替换 GTAGSLABEL
$ export GTAGSLABEL=native-pygments
$ gtags --explain
...
- File 'test.c' is handled as follows:
suffix: |.c|
language: |c|
parser: |C|
library: |built-in|
...
# 这下能找到了
$ global -x main
main 7 test.c int main() {
我的 global 版本是 6.6.5，请问跟版本有关系吗？还是我的 pygments 没装对？
$ which pygmentize
/home/xxx/.pyenv/shims/pygmentize
$ where python -m pygmentize
/home/redacted/.pyenv/shims/python
/home/redacted/.pyenv/shims/python
/usr/bin/python
/home/redacted/.pyenv/shims/pygmentize
/home/redacted/.pyenv/shims/pygmentize
/usr/bin/pygmentize
kinono
3
global 也需要用到 ctags 吗？
Global 扫描原生支持的语言不需要用 ctags，不支持的语言可以借助 ctags 和 pygments 来扫，仍然可以生成 gtags 格式的文件。
把 GTAGSLABEL 改成 native-pygments 的话倒是正常
这个意思就是能用 global 扫的就用 global（native），不能的就用 ctags+pygments。设为 pygments 的话意思就是全部都用 ctags+pygments。
1 个赞
嗯，这一项我倒是看 global 怎么用的时候知道的，global 内置支持了几种语言（从 gtags --explain 中显示的 library 里也能看出来）
只是不知道在用 pygments 的时候需要用到 ctags，然后看了看 conf 文件才明白咋回事
实际使用的话，是用哪种比较好呢？是不是全都用 pygments 好一点，毕竟我看 pygments 一直都在更新，而 global 的更新速度挺慢的
好吧，还是谢啦，我这边测试没什么问题，挺好用的，开箱即用太方便我这种苦手了
请问下citre可以和lsp-mode同时使用吗，需要如何配置
kinono
8
看 wiki。里面 company 后端的例子在这次重构之后可能不能用了，其他的应该都工作。
Edit: company 后端的部分也可以工作了。我写了一个宏，可以直接把 Citre 的补全后端变成一个 company 的后端。
用cape，把citre-completion-at-point赫lsp-comoletion-at-point绑定成一个capf应该就可以解决问题了吧？
kinono
10
应该是可以的，不过我不用 cape 也没有试过。如果您试验过可以的话，可以在 wiki 里写一下，谢谢 
kinono
12
不是，个人只是用 global 查引用，顺便做了个全功能 global 后端 
ctags 在大多数场合比 global 好用。为了防止其他读者也产生误解，我在原帖内加了说明。
2 个赞
kinono
14
这个步子太大了。之前作者给我邮件解释过不想记录引用的原因，主要是他觉得还没想明白「引用」的定义，次要的原因是记录引用会让 tags 文件过大。
其实想一想也能明白，编程的时候几乎每一行都要用一些符号，每用一个符号就在 tags 文件里占一行，最终 tags 文件要比代码库还大了。global 使用二进制数据库，不用拘泥于一行一个 tagline 的格式，可以做得小很多。
ctags 也有 reference tag 的概念，现在只用来记录一些对外部文件的引用，比如 include、import 等，看这里。这个最终目的是让 ctags 能从喂给它的文件自动找出所依赖的外部库，并且连库一起扫描了。
zhscn
15
作为对比可以看 ccls 的缓存大小（相比 clangd, ccls 的引用信息更丰富）：
项目本身（src目录）是584MB。
ccls缓存目录的大小是2.75GB。其中引用占比不太清楚，但是想来不会太小。
（即便是这样我还经常感觉 ccls 的引用信息不够全面）
rua
17
话说这个现在可以用吗，例如我写 go 的话 ctags 会自动找到 import 的 lib 然后包含它们的 tag 吗（不知道理解的对不对）
kinono
20
刚刚给 Citre 的补全增加了 company-docsig 和 company-kind 属性，现在使用 company 或 corfu + kind-icon 补全就可以显示图标，同时 echo area 会显示函数签名：
如果备选项不是函数，或 tags 文件没有记录签名，则会显示 tag 中记录的用来搜索的 pattern（通常就是定义所在的那一行）：
仅适用于 tags 后端，global 后端没有记录这些信息。
PS：有点后悔给 Citre 创建了两个帖子，现在这个更新有点不知道该发到哪个里面
