redguardtoo/counsel-etags: Fast, energy-saving, and powerful code navigation solution
更新,
btw, 在考虑把counsel-etags(代码导航)和company-ctags(代码完成)移植到只使用emacs native api的版本,有人感兴趣吗? 这两个插件唯一的依赖就是ctags,另外elisp代码经过了优化,性能很好.
一直在用，不过现在pc都打开的少了，手机android gui上就写点elisp和org, 似乎也没必要用这个
是因为支持emacs etags的legacy code.现在不需要这个string-match了,以修正
谢谢,修掉了. 我把company-ctags和counsel-etags合并成一个新包吧,内存使用可以节省一点,使用emacs的native api,不依赖第三方包.
使用consult, 有类似的包吗? 我没有使用 counsel
不太清楚,不过只要用native api completing-read的包一般都可以和consult一起用.
是存在另外一个包叫做consult-etags吗？和这个有什么区别。 我已经使用了rbtagger，是否可以和这个包一起使用？
目前应该没有. counsel-etags目前是和counsel紧密绑定的. rbtagger不确定能和consult一起用.
一个包如果使用completing-read来处理"用户从多个选项中选中一项", 那么consult或counsel可以替换completing-read来提供定制的UI.
我最早开发的counsel-etags的时候所有"用户从多个选项中选中一项"的场景都用了ivy-read而不是completing-read因为看起来前者远远优越于后者且提供了很多额外功能.
rbtagger看起来用了很多xref的api,不清楚其更底层是否用了completing-read.
这个预备中的新包有什么特性？能够和citre比较么？我一直在寻找比较轻量的citre替代品，它在我的emacs上表现得很差，远没有示例中的流畅。
应该性能还可以.counsel-etags我用linux kernel测性能不错. 也许新版本可以再加速一点. 除了性能优化外应该不会加什么新特性.现在AI够强大了,我就专注于用ctags完成简单的代码导航和代码自动完成就可以了.
对，citre 太重了，用了一段放弃了。
有一个elisp技巧我用在company-ctags上效果很好,
分析整个工作流, 用ctags产生tags 文件很快,也不会阻塞emacs ui操作,但elisp把tags数据读入emacs是非常慢的过程,
所以在tags 文件更新后,我可以把新的tags文件和旧的tags 文件用命令行程序diff 产生一个 patch,然后分析patch的内容就可以了. patch是一个很小的文件,用elisp分析的代价很小.
这个技巧没法用在counsel-etags因为它要支持emacs etags(代码文件路径不是tags文件里每行都有).
现在我打算只支持vim tags格式了,那么这个技巧就可以用于提速代码导航.
期待新包
原来如此，我还觉得etags有emacs原生支持，要支持它应该并不困难，没必要放弃
