emacs中有没有使用rg来搜当前buffer的内容的插件

emacs里面rg搜索很快,但是都只能是针对文件的。

有没有能使用rg来搜buffer的插件呢?

swiper和occur都可以搜buffer,但是文件大了我感觉这俩货都有点卡。

我就想有没有已有的轮子了?

问题补充:有朋友说到使用counsel-grep-or-swiper。我试了下,如果buffer没有和文件关联的话,counsel-grep是用不了的。也就是说此时counsel-grep-or-swiper还是只能使用swiper的。

我是想要只对buffer的,无论它是否关联文件。

swiper和occur都可以满足,但是我觉得大文件还是有点慢。感觉要是他们的backend能换成rg会不会更快点?

counsel-grep-or-swiper 大文件自动用grep安排

这个我知道,我感觉grep还是没有rg快 :slight_smile:

那就让他用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没有关联文件的时候是不可用的。所以上面这个改法还是不太能满足我的要求。

不过还是谢谢您 :slight_smile:

你这不是伪命题吗?rg能搜索 buffer 吗?如果是 buffer,老老实实用 isearch 或者 swiper 吧

代码看起来似曾相识哪 :joy:

From Centaur Emacs :smile:

其实吧,可以用echo把buffer string从管道传递给rg。就可以了,不过大文件就怕Bash爆炸

:joy::joy::joy:

那不如保存成一个文件随便怎么搞都行

保存成文件或者用管道都不太可行啊,保存成文件的话要么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算了。

后面有时间再搞啦 :slight_smile:

谢谢。

其实很可能是emacs的图像渲染太烂导致卡顿,而非cpu密集型运算卡顿

这个我就没细研究了。反正就是这么个问题。 哈哈。

跟图像渲染关系不大吧,终端下也是一样的。

输入几乎不耗资源,occur基本是全力在运行,问题在于occur全力运行也达不到实时出结果。

需要让occur自己多线程才行,即把一个buffer分成多个部分,起多个线程来处理这多个部分,但这样逻辑就复杂很多了,emacs的架构目前很难实现

是的,所以我就不再折腾了