Citre: 先进的 Ctags 前端

citer-peak 在 tui 下 · → func1 → func2 → [func3] 这里的箭头显示的是 -,这个是预期的吗,还是说 -> 更好一些

是故意的,你可以看下 citre-peek-chain-separator 定义处的注释。当然这个只是我自己测出来的问题,也可能你的终端不会有这个问题。

Edit: 刚看到你问 -> 好不好,其实也行吧,只是比起 gui 要多占一个字符了。我觉得那块地方还是比较宝贵的。

1 个赞

楼主好!一段时间没更新citre,感觉强大了好多!想请教一个问题:如何排序citre提供的定义呢?

比如在c++中,下面这段代码

typedef struct {
   int x;
   int y;
} example;

当我们出现example_instance.的时候,我们肯定希望x,y排在最上面

同样的道理,在verilog中也有类似的语句

	typedef struct packed {
		logic valid;
	        a_t foo;
		resp_t bar;
	} verilog_example;

请问如何配置才能让我输入一个verilog_example.的时候后面提示补全的valid能排在最上面呢? 感谢!

edit:

一个可行的思路是在输入.之后查询.之前的实例的定义,然后根据它包含的元素自动补全,把包含的排在最上面

你说的这个我其实考虑过,但一直没有做。

问题出在查询实例定义的这一步。因为 Citre 主要是靠匹配 tag name,经常一查就是几十个定义,我们怎么知道里面哪个是我们要的那个 instance 呢?

当然,这只是我的预测。或许实际上不存在这个问题。比方说我们留下 typeref 是 「struct」的那些,或者再用一些其他条件过滤以后,就不剩多少了。

我认为正确的思路还是允许用户二次或一次过滤,就是你直接告诉 Citre 「我要这个结构体的成员」。ctags 的弱项是「智能」,但 readtags 提供了很好的过滤工具,应该扬长避短才是。

Edit: 实际上想要敲完 . 就跳出补全也是很难的。这个时候因为没有符号的开头一部分做提示,我们无法用二分搜索,只能过滤整个 tags 文件,找出所有的 member 再排序,对大一点的工程肯定是无法接受的。

Edit: 事实上针对上面说的这个情况,如果有生成 qualified tags,就不需要二分搜索了。

这个必须得做点语法分析或词法分享。

  • 如果不考虑lsp,那只能考虑tree-sitter。

我会做一个tree-sitter的版本,有谁要一起吗?

我的想法是,比如我们现在有个symbola.b.c.

我们想要补全,我们就先查询C的type

如果c是一个module instance,我们就查询C对应的定义里面的reg或者wire

如果c是一个struct,那我们就用补全struct里面的成员内容

我不太清楚ctags的内部实现,但是看自动补全出来的提示是有类型的,感觉应该是可以做到的

对,是的。tree-sitter实际上对sv的支持也很一般。。。

可以做是肯定的,但是有三个问题:

  1. 性能
  2. 由于 ctags「不准确」的天性,你不想要的可能也会排到前面来,所以效果不一定好。

我可以对 C 语言先试试(verilog 我不懂),但这个事的优先级会低于给 citre-peek 添加二次过滤界面。

多谢楼主!祝楼主写citre peek顺利!

最近升级了citre新版本后,有时tags文件中找不到定义,总提示一个“Can’t find definition. Update the tags file and search again? (y or n) ”。这个提示可以关掉吗?每次都提示挺烦啊。 谢谢;

我可以加一个选项,但我比较好奇为什么会觉得这个烦呢?有找不到的定义时,确实应该更新 tags 文件吧。

哈哈,因为我有时候看的代码确实不太完整啊。。。

用内核代码使用ctags,貌似头文件里的函数没有被tags。请教下是什么原因呢?

ctags 认为头文件的语言是 c++。生成 tags 时需要选择 C 和 C++ 两个语言,或者你用命令行的话就是

--languages=c,c++

如果没有解决问题,请提供生成 tags 文件的详细步骤或命令行。

2 个赞

可以了,多谢。

刚开始用上了,但这个问题实在是会让人误解:In which dir you want to use tag file?其实是想问 project path, 然后作为 tag 文件的 key,是不是应该这么问: Please specify the project path which is used as a key to find the tags file,或者类似的。

  1. 这里没必要再和「工程」的概念钩挂起来。楼上就有同学在工程的不同子目录用不同的 tags file 的。

  2. 只有把 tags 文件存到 cache dir 的时候才有 key 的说法,直接存到那个目录底下就没有了。并且这属于实现,不是行为。

你误解成了什么呢?我觉得这个问题还是挺清楚的。或许另一种问法是:

  • When in this dir, use the tags file:
  • Use the tags file for files(或者 buffers?)in this dir:

其实说的就是「你打开这个目录下的文件,Citre 就会帮你找到这个 tags file」。

其实我也看不懂这个问题,哈哈哈哈哈哈

看来是个问题。你觉得我楼上给出的备选哪个好看一些?或者有没有更好的说法?