Snails超级快的模糊搜索框架


#173

是的,我自己小改了下snails了代码。刚提交了个PR,不知道猫大会接受不


#174

已经合并了,我完全不使用 evil 的, 已经有三个人给我提交 evil 相关的补丁了,而且大家的使用习惯还不一样。

如果还是众口难调的局面,我会考虑移除 evil 的代码,evil 的用户应该用 snails-mode-hook 的方法去配置 evil 相关的设置。


#175

看到 snails 的第一眼,就想起 vscode 的 cmd+shift+p,而它在 vscode 中,经常被人称为神器!(我也是道听途说的,但感觉很靠谱… :see_no_evil:

回到问题,「越来越乱」的问题其实可以非常容易得到解决。按照目前设计,只需要自定义 backend 集合,可以较好地解决 backend 过多的问题,懒人可参考:https://github.com/cosven/.emacs.d/blob/master/elisp/init-snails.el#L8。

长远来看,可以有另外一个发展思路:参考 vscode 的功能设计。解析 input 来自动过滤 backend。像 vscode 一样,加个 > 前缀就只搜索 command,不加前缀就只搜索 buffer。我觉得 snails 也完全可以采用这种思路,实现也非常简单,判断一下字符串前缀就可以。用户体验上还可以向后兼容,简直 perfect。

想搞复杂点的话,可以自己对 input 进行词法分析,到时干啥都行…(不过我感觉这种思路可能性应该很小,毕竟没必要搞这么复杂)

非常看好 snails!毕竟同为操作系统的 macOS 上有 alfred/spotlight;Linux 上也有 albert 等。KDE 有 alt-f2;GNOME 也有全局搜索。嗯,我们 Emacs 操作系统以后也有 snails 啦 :see_no_evil:


#176

你的插件代码已经合并了。

关于你说的前缀问题,我觉得非常好,这样可以默认不用那么多后端,用户可以自定义的进行搜索。

比如:

  • at: snails-backend-awesome-tab-group.el
  • bm: snails-backend-bookmark.el
  • bf: snails-backend-buffer.el
  • cb: snails-backend-current-buffer.el
  • et: snails-backend-everything.el
  • fd: snails-backend-fd.el
  • im: snails-backend-imenu.el
  • mf: snails-backend-mdfind.el
  • pt: snails-backend-projectile.el
  • rf: snails-backend-recentf.el
  • rg: snails-backend-rg.el
  • !: all backends

不同的前缀搜索不同的后端,如果前缀是!: 就搜索所有后端


#177

我觉得前缀越简洁越好,尽量用符号


#178

从可用性(UX)的角度,同意越简洁越好的想法;也同意尽量用符号,并且是那种表意明显,有一定使用历史的符号。比如 vscode 的 >,我觉得就挺好的。

另外,我觉得这样的工具,它的用户体验其实非常重要,比如性能就非常关键。

我又去体验了一下 vscode 的功能设计:

  1. 使用者按 cmd+shift+p 弹出来的窗口自动带 > 前缀,按 cmd+p 不带前缀
  2. > 前缀搜 Command,类似 Emacs 的 Alt-x,不带前缀搜文件(包括项目文件和 recentf)
  3. 不带前缀时:它的 placeholder 是 “Type ‘?’ to get help”
  4. 按 ? 后可以发现几个前缀:
  5. @ -> symbol
  6. : -> goto line

根据自己个人过去的使用经验,我有以下几个看法(ps:根据个人能力和时间,我预计自己贡献的代码会比较少,所以这里提的看法仅仅是一个看法。我尽量给自己的看法都加上自己的理由):

  1. 我觉得如果 snails 前期可以不预设,或者只设一两个最基本的前缀(毕竟如果前缀加上去,就不好撤回来了),以后让用户自己来配置 {前缀: backend group} 这个对应关系,snails 只管最基本的前缀
  2. 前缀尽量是一个字,甚至更好地交互方式(懒猫提到的三个字母的前缀,我觉得还是有点繁琐 :see_no_evil:
  3. 按照功能来分前缀,而不是按 backend 来分。 我感觉有很多 backend 是同质的,只不过他们在不同平台可能对应不同的 backend,以后发展强大了,生态好了,这种情况应该会尤其明显:功能基本相同的 backend,可能有好几个实现版本,比如有些性能强大,有些简洁好用(就类似 ivy 和 helm 这样的同类竞品)。

小结一下 :see_no_evil:

说这么多废话的原因是我自己对这样一个工具抱有很美好的幻想,(alfred 应该是这类工具中比较成功的一个了)(当然这不是要求开发者为我写功能啥的),而我认为这类工具尤其重要的几点有:

  1. 响应速度!!!!!!!
  2. 简洁,一定要简洁(功能简洁、少打字…)
  3. 具有相对优雅的默认行为(用户体验)(我觉得 snails 目前这个默认行为还不错)
  4. 强大的可扩展能力(不仅是扩展搜索类 backend,既然是个全局 bar,它可能还要承担执行命令等使命)

嗯,我的废话(个人想法往往很局限,并且可能被之前经验所束缚…)告一段落…


#179

vscode用的符号,但字母按起来更快,类似于alfred


#180

是比较像,但是设计理念和目标差别很大。snails 只着重在搜索功能上,vscode 的更像 minibuffer,什么都可以从这个入口进入,搜索只是其中一小部分功能。你所说的长远思路,怕是没那么简单啊,得包罗万象,不如用 ivy-posframe 或者 minibuffer 了。我估计这不是懒猫的初衷。


#181

我倒是觉得,应该考虑后缀,先搜出所有的,觉得看不到需要的,再加个后缀限制


#182

也可以像magit那样加搜索条件


#183

我当时看代码,上一个版本是会检查 evil 的默认 state 的,但是不知道为什么又删了。

本来也想研究一下怎么改一下代码,可以通过配置设置,奈何最近很忙。。。

看了一下加的判断,感觉这两个判断好生硬啊 :rofl:

    (if (fboundp 'evil-insert)
      (evil-insert 1))
    (if (fboundp 'evil-emacs-state)
        (evil-emacs-state))

就像 PR 说的,我也感觉通过配置,或者 hook 处理可能更好一些


#184

+1 感觉后缀比前缀好 , 先搜再想要什么


#185

后缀处理起来麻烦吧,C-a 输入前缀就好


#187

请问如何想要 helm 那种 follow mode 在搜索结果里面根据聚焦自动切换 buffer 显示的内容用你现在这个 UI 是否会有点冲突?这个弹出的窗口可以像 helm 显示在底部吗?


#188

是啊,我也觉得这样不好。可我试着加hook的时候,不知道怎么回事,重新启动emacs后第一次调用snails的时候是有效的,关掉snails窗口再重新调用就无效了,也不知道怎么回事。


#189

请用helm,那不是snails的设计初衷


#190

最新版已经可以了,请重新试一下


#191

主要是我根本不用 evil, 我也不知道什么是最好的,而且我感觉evil用户也有不同的习惯。

最新版我直接删除了 evil 的代码,大家可以通过 snails-mode-hook 来自定义 evil 配置


#192

其实,我写 Snails 的时候就思考了这些问题,我对Snails的考虑是有几个出发点:

  1. 整体架构一定要快,不管搜索后端是用什么方式实现的,都不能卡,目前已经通过架构来实现了
  2. 随着后端越来越多,大家对默认后端列表的习惯一定不一样, 大家可以通过自定义 backend 列表来快速包装自己喜欢的搜索后端列表

Snails 最开始的目标已经实现:快、实现简单、不影响窗口布局

至于类似 VSCode 这种前缀的方式,从我内心来看,肯定是比没有任何前缀复杂的,因为不够直觉,有一定的学习门槛和记忆成本,但是好处是,可以动态按需加载后端,而不是像 Helm 那样一股脑全部都在搜索,虽然Snails的性能不会受到后端的影响,但是一股脑数据全部过来了,用户筛选后端也是成本。

如果要做前缀后者后缀,可以从以下几个方面去考虑:

  1. 默认只做 buffer 搜索,这是最通用的
  2. 通过不同的修饰符来定义不同的分组,比如 f: 只是搜索文件名(fd, mdfind, everything, projectile 等等), F: 搜索文件内容 (ripgrep)
  3. 至于是前缀还是后缀,我觉得需要再思考一下,也想看看大家的讨论

我认为Emacs在代码导航方面,有几个组件需要共存:

  1. minibuffer,就是用来输入命令的,有按序补全和记忆功能就很好,其实 smex 就够了
  2. 代码或者英文语法补全,company/auto-complete 就是最佳选择
  3. 专注于搜索的操作,应该聚焦于模糊搜索后马上回车执行默认命令,这也是 Snails 对自己的定位

所以,Snails的定位是专注于搜索相关的功能,而不是用来替换 Minibuffer 或者 Company,大家可以看看,像Helm这样,很多人因为喜欢Helm,把所有的补全功能都用Helm来操作,其实很多时候,并没有 Smex 和 Company 做的好。

就像很多人喜欢一门编程语言后,总想用这门编程语言把所有的功能重写一遍,殊不知,编程语言总会有更新的出来,今天的Rust就像当年的Haskell一样,以后还会有新的编程语言出来,但是重写一直都不是正确的定位和发展方向。

最后,我认为Snails能够把搜索补全这个领域做好,和Smex、Company形成良好的互补关系就是最好的发展方向。


#193

@manateelazycat

懒猫,我发现 buffer-filename 这个变量只在 snails-backend-current-buffer.el 出现在了这一行

snails.el snails-core.el 都没有出现,这是不是个 typo ?