emacs 在一个大项目的项目中查找文件答案

【问题标题】：emacs find file in project on a big projectemacs 在一个大项目的项目中查找文件
【发布时间】：2011-11-01 17:45:48
【问题描述】：

在 vim 中，有一个名为 command-t 的神奇插件，可以让您模糊搜索项目中的所有文件。我们有一个相当大的 Rails 应用程序，其中包含大量文件，它能够处理它几乎没有任何减速。

尝试了一些方法（例如 ffip、textmate.el 的 command-t 和 rinari 的 rinari-find-in-project）。 UI 很棒（我

目前我更多地使用 rinaris 导航命令和 ido-find-file。在它们两者之间，这是一个可用的设置，但如果在项目中有一个疯狂的快速模糊查找，那就太好了。

有谁知道比我尝试过的更高效的脚本吗？

【问题讨论】：

这里还有一些类似这样的包：emacswiki.org/emacs/LocateFilesAnywhere
尝试 M-x 任何东西，如果你还没有这样做，进行比较
我在下面发布了基于任何解决方案的解决方案。如果您有任何问题，请告诉我。

标签： emacs

【解决方案1】：

我的混合物的 github 代表在这里：https://github.com/lewang/anything-project-files

我添加了一些其他任何资源，以便任何项目查找都可以替代“C-x b”。所以这个想法是，当你点击“C-x b”时，你正在完成对现有缓冲区，最近通过recentf的文件（我个人破解它以使用“session.el”，但它是一个小差异），当前目录中的文件，文件在当前的项目。我觉得它很方便。

我已经使用了一段时间，但它没有经过很好的测试，所以请报告你发现的任何错误。

【讨论】：

这太棒了 :) 我的问题是我们的项目大约有 6.5k 个文件，而且任何东西（至少在我的笔记本电脑中）都会被这么多东西呛到。打算在工作时在我的 i7 上尝试它，如果这不起作用，请将几个不同的源限定为某些目录（例如，测试是总文件的 1.5k），但非常感谢这一点，很确定这是我要去的轨道
我的项目有 2.5k 个“有趣”的文件。我刚刚将它增加到 7.5k 进行测试，一切正常。加载时间大致相同——在我的 2.5 GHz core-2-duo MBP 上大约需要 0.5 秒。
加载时间很好，这是您尝试缩小结果的时间。所以在我的 6.5k 文件项目中，里面有一个 skus 文件夹，里面有一个 show.html.erb 文件和一个 index.html.erb 文件。当我搜索“skus show”时，它在找到文件时会出现明显的停顿。当我尝试删除“显示”并将其替换为“索引”时，会有更长的停顿。我在想的是我不太关心迁移（这是> 1k文件），如果我可以将测试（另一个1.5k文件）范围扩大到它自己的东西，希望这足以摆脱（或减少）停顿
我仍然无法重现减速。也许你可以把 github 上“find_interesting ”的输出发给我？
这个链接404s 现在。我在哪里可以找到更新的 repo？

【解决方案2】：

尝试https://github.com/redguardtoo/find-file-in-project，它使用GNU Find 或BSD Find 来查找文件。没有什么能比得上 C 的速度了！

M-x find-file-in-project-by-selected 是您需要使用的唯一命令。

我在一些石器时代的上网本上测试了 50000 多个文件，没有任何问题。

默认情况下，它使用高效的ivy-mode 过滤候选者并使用ido-mode 作为后备。我用 300 万候选人 测试了 ivy-mode。现在您知道 Emacs Lisp 本身已经足够快了。

在*nix，内核为find提供缓存，所以如果你搜索相同输入的文件，响应是即时的。

此外，ivy-mode 会自动将最后的搜索结果缓存在 Emacs lisp 变量ivy-last 中，因此您可以通过M-x ivy-resume 获取以前的候选人而无需打扰Find。

您可以(setq my-cached-result ivy-last) 将ivy-last 存储到另一个变量中。那你可以M-x my-ivy-resume:

(defun my-ivy-resume ()
  (interactive)
  (let* ((ivy-last (if my-cached-result my-cached-result ivy-last))
         (default-directory (ffip-get-project-root-directory)))
    (ivy-resume)))

通过这种方式，您可以存储最后 1000 个结果并重新使用它们；）

更新 1：从版本 6 开始，ffip 使用 Emacs 内置 API completing-read 而不是 ivy-read。所以像ivy-resume 这样的常春藤特定功能还不能使用。您可以降级到版本 5。 ffip 只是使用 Emacs 内置 API 的单个 Emacs Lisp 文件，因此很容易降级。

或者等待常春藤解决问题（见https://github.com/abo-abo/swiper/pull/2785）

更新 2：从 6.1.1 版本开始，我添加了命令ffip-find-files-resume。它比ivy-resume 更强大。例如，它可以重放任何先前的动作。 ivy-resume 只能重播上一个动作。

【讨论】：

my-viy-resume gives: 最后一个会话与'ivy-resume'不兼容`错误，我们该如何解决？
降级到版本 5。

【解决方案3】：

取决于模糊匹配的含义。大多数模糊匹配本质上都很慢，但一些轻量级的伪模糊算法相当快。一般来说，您最好使用 regexp 搜索，而不是模糊匹配搜索。

无论如何，这个问题有两个部分：

Icicles 可以帮助解决这两个问题：

Project定义、管理等
搜索一个项目或其中的一部分：
- Searching file content（以及搜索和替换）
- Locating files

【讨论】：

现在正在研究 icicles 和任何东西 + eproject，一旦我投入更多工作就会更新内容
我有一个基于任何东西 + rinari + 我的自定义 ruby 脚本的解决方案，它通过 .gitignore 只查找有用的文件。它具有缓存，并且像 slickedit textmate 版本一样快速拆分。 ;) 不幸的是，我要到这个周末才有时间打包它。当我这样做时，我会发布它作为答案。
@event_jr 听起来绝对令人愉快：D

【解决方案4】：

你可以试试gpicker。如果你通过-t guess，它会尝试通过scm后端如git找出相关文件。

我使用以下sn-p在项目中查找文件，其中项目根由eproject确定。

(require 'iy-dep)

(defcustom iy-gpicker-cmd (executable-find "gpicker")
  "Default font"
  :type 'file
  :group 'iy-config)

(defun iy-gpicker-find-file (dir)
  (interactive
   (list
    (or (and current-prefix-arg (ido-read-directory-name "gpicker: " nil nil t))
        (and (boundp 'eproject-root) eproject-root)
        (and (not current-prefix-arg) (ido-read-directory-name "gpicker: " nil nil t))
        (if dired-directory (expand-file-name dired-directory) default-directory))))
  (when dir
    (with-temp-buffer
      (call-process iy-gpicker-cmd nil (list (current-buffer) nil) nil
                    "-t" "guess" "-m" dir)
      (cd dir)
      (dolist (file (split-string (buffer-string) "\0"))
        (unless (string-equal file "")
          (find-file file))))))

(provide 'iy-gpicker)

【讨论】：

这看起来很有趣。 ATM 即时使用模糊文件查找器，它依赖于 ruby gem（我不是真正的粉丝）我会给 gpicker 一个尝试

【解决方案5】：

您可能想要IdUtils，但不熟悉您提到的所有其他技术，我无法确定。

【讨论】：