emacs里面rg搜索很快,但是都只能是针对文件的。
有没有能使用rg来搜buffer的插件呢?
swiper和occur都可以搜buffer,但是文件大了我感觉这俩货都有点卡。
我就想有没有已有的轮子了?
问题补充:有朋友说到使用counsel-grep-or-swiper。我试了下,如果buffer没有和文件关联的话,counsel-grep是用不了的。也就是说此时counsel-grep-or-swiper还是只能使用swiper的。
我是想要只对buffer的,无论它是否关联文件。
swiper和occur都可以满足,但是我觉得大文件还是有点慢。感觉要是他们的backend能换成rg会不会更快点?
cireu
2
counsel-grep-or-swiper
大文件自动用grep安排
cireu
4
那就让他用rg
(let ((command
(cond
((executable-find "rg")
"rg -i -M 120 --no-heading --line-number --color never '%s' %s")
((executable-find "pt")
"pt -zS --nocolor --nogroup -e %s")
(t counsel-grep-base-command))))
(setq counsel-grep-base-command command))
谢谢。不好意思,可以是我没有说清楚。我又把问题补充了一下。
counsel-grep在buffer没有关联文件的时候是不可用的。所以上面这个改法还是不太能满足我的要求。
不过还是谢谢您
你这不是伪命题吗?rg
能搜索 buffer 吗?如果是 buffer,老老实实用 isearch 或者 swiper 吧
cireu
9
其实吧,可以用echo把buffer string从管道传递给rg。就可以了,不过大文件就怕Bash爆炸
保存成文件或者用管道都不太可行啊,保存成文件的话要么I/O爆炸,要么就一堆垃圾文件。用管道的话shell爆炸
这个应该有点麻烦
你需要同时知道buffer的存储机制和rg的搜索方法
然后写个module封装rg去搜索buffer的内容
rg好像是rust写的 还得学会rust
你看到了吧 这么简单的问题 需要涉及这么多的东西
1 个赞
是的,这个是有点麻烦,我不准备搞了。哈哈。谢谢啦。
另外,irc上也有人让我从shell-command-on-region上找灵感。
想起来弄这个,是最近在搞isearch。我把它弄来输入一个字符,就自动调一下isearch-occur来把当前buffer中的所有match都是显示出来。
遇到buffer稍威大一点,就有点卡。我觉得卡的原因,就是因为occur太慢了。所以才有这样一个问题。
最后我的解决办法是,定义一个输入的前缀长度,小的bufer中,可能iserach输入超过2个字符后才自动调用isearch-occur。大的buffer,这个长度可能就在4,5个的样子。
我这个有点重复造轮子,swiper其实做得很好了。不过,我就是受不了buffer一大,swiper就卡那一两秒。
swiper这个问题是有issue的,abo-abo也搞了一个“差不多可用的代码”,在 这里 ,我问他了,他说最近没时间把这个“差不多可用的代码”合入。
所以,我就自己干啦…………
我觉得可以用counsel-grep-or-swiper
这个思路
这个可以看一下。我之前折腾了一下。主要是定制isearch。发现emacs的多线程还是不太能满足我的需求。也查了一些文档。
看起来,emacs在同一时间,还是只能run一个线程的。所以即使使用make-thread,如果其中有一个线程是cpu密集型的,还是一样卡住。我上面这样在isearch中自动调用occur就是这样。即使我使用make-thread新建一个线程来调用occur,在buffer大一点的情况下,isearch的输入还是会被卡住。
比起来,大的buffer经常搜的话,swiper还是好用的。除了调用swiper的时候可能会卡一小会儿。
我现在关闭了这个功能。绑定了一个好用的按键来调occur算了。
后面有时间再搞啦
谢谢。
cireu
16
其实很可能是emacs的图像渲染太烂导致卡顿,而非cpu密集型运算卡顿
输入几乎不耗资源,occur基本是全力在运行,问题在于occur全力运行也达不到实时出结果。
需要让occur自己多线程才行,即把一个buffer分成多个部分,起多个线程来处理这多个部分,但这样逻辑就复杂很多了,emacs的架构目前很难实现