citer-peak
在 tui 下 · → func1 → func2 → [func3]
这里的箭头显示的是 -
,这个是预期的吗,还是说 ->
更好一些
是故意的,你可以看下 citre-peek-chain-separator
定义处的注释。当然这个只是我自己测出来的问题,也可能你的终端不会有这个问题。
Edit: 刚看到你问 ->
好不好,其实也行吧,只是比起 gui 要多占一个字符了。我觉得那块地方还是比较宝贵的。
楼主好!一段时间没更新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的支持也很一般。。。
可以做是肯定的,但是有三个问题:
- 难
- 性能
- 由于 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 文件的详细步骤或命令行。
可以了,多谢。
刚开始用上了,但这个问题实在是会让人误解: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,或者类似的。
-
这里没必要再和「工程」的概念钩挂起来。楼上就有同学在工程的不同子目录用不同的 tags file 的。
-
只有把 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」。
其实我也看不懂这个问题,哈哈哈哈哈哈
看来是个问题。你觉得我楼上给出的备选哪个好看一些?或者有没有更好的说法?