Vim 的自动完成速度慢得令人难以忍受

发布于 2024-08-20 01:58:55 字数 237 浏览 6 评论 0原文

大多数时候,Vim 中的自动完成功能对我来说效果很好,但有时它似乎正在扫描当前文件引用的文件,然后它变得非常慢,有时需要几秒钟才能将焦点释放回我身上。

有时,Vim 简单地告诉我它是“扫描”,其他时候,它说“扫描标签”

我只在 Ruby 文件中发生这种情况,而且大多数情况下当文件中有 require 时发生。

我的猜测是,这是某种检查相关文件的自动完成选项的功能,但我并不真正需要它,并且更喜欢更快的自动完成。

Most of the time the autocomplete feature in Vim works nicely for me, but sometimes it seems to be scanning files which the current file references, and then it becomes painfully slow, sometimes taking several seconds to release focus back to me.

Sometimes Vim tells me simply that it is "Scanning" other times, it's saying "Scanning tags"

I've only this happen in Ruby files, and it happens mostly when there is a require in the file.

My guess would be that this is some kind of feature which checks related files for autocomplete options, but I don't really need that, and would prefer quicker autocomplete.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

彻夜缠绵 2024-08-27 01:58:55

正如我在评论中提到的,我也遇到了同样的问题。这是我发现的;

有一个设置告诉 VIM 在哪里寻找补全,称为 complete

:set complete
complete=.,w,b,u,t,i

这是默认值。我的问题是(实际上是..)“i”,它扫描所有包含的文件。这里有两个问题,第一个问题,找到所有这些文件可能需要相当长的时间,特别是如果您像我一样遇到

:set path=**

第二个问题,一旦找到,就需要阅读它们,并且如果您使用网络文件系统(我使用的是clearcase)查找和读取所有这些文件都可能会触发缓存未命中,从而使其速度非常慢。

我现在已经删除了 i,因为我有一个标签文件,而且通常情况下,我的缓冲区中也有相关文件(已加载或已卸载),这些文件将作为“b”和“u”的结果进行搜索'。

用于

set complete-=i

从列表中删除 i,请注意,这是缓冲区本地的。

As I mentioned in a comment I had the same problem. Here's what I found;

There's a setting telling VIM where to look for completions, called complete.

:set complete
complete=.,w,b,u,t,i

this is the default value. My problem is (was actually..) the 'i', which scans all included files. Here are two problems, first one, finding all those files might take quite a while, especially if you, like me, have

:set path=**

Second problem, once found, they need to be read, and if you're using a networked file system (I'm on clearcase) both finding and reading all those files might trigger cache misses, making it painfully slow.

I've removed the i for now, as I have a tags-file and more often than not, I also have the relevant files in my buffers (loaded or unloaded) which will be searched as a result of 'b' and 'u'.

Use

set complete-=i

to remove the i from the list, note that this is local to the buffer.

倾其所爱 2024-08-27 01:58:55

自从升级到 Vim 7.3(从 7.2)以来,遇到了非常相似的问题:我使用的是(优秀) ACP 插件 和较长的源文件(C 文件,1700 LOC)中,当我在文件底部附近进行编辑时,弹出窗口需要很长时间才能跳过建议。

使用PerformanceValidator(来自Softwareverify),我发现一些折叠方法被一次又一次调用,导致处理器负载非常高且完成缓慢。

我的解决方法是设置 foldmethod< /a> (fdm) 到 手册< /代码>。这解决了它......

Had a very similar problem since upgrading to Vim 7.3 (from 7.2): I was using the (excellent) ACP plugin and in longer source files (C-files, 1700 LOC), the popup took ages to jump through the suggestions when I was editing near the bottom of the file.

Using the PerformanceValidator (from Softwareverify), I found out that some fold methods were called again and again and lead to very high processor load and slow completion.

My workaround was to set the foldmethod (fdm) to manual. And this solved it...

久伴你 2024-08-27 01:58:55

您有您正在从事的项目的标签文件吗?如果没有,请尝试使用 exuberant-ctags 生成一个,Vim 应该使用 taglist 插件来选择它。

Do you have a tags file for the project you're working on? If not try generate one with exuberant-ctags and Vim should pick it up with the taglist pluglin.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文