sublimetext 2 真的是用c++写的吗，处理一个160k的css反应迟缓

[rqrq]

ctrl+f搜索url标签都能卡一会
更别说我想要用ctrl+h把每个class都弄成一行了。
直接用虚拟机里的editplus搞定了，虽然功能不咋样但是效率靠谱。

ubuntu 12.04.3 + 4G + i3

[tcsky]

常见的几个编辑器好像都是基于Scintilla组件~ 都没法编辑大文件 那个什么什么 emeditor 可以,而且很流畅

[ivenvd]

@rqrq 你觉得 Vim 会在语法高亮算法上有问题？正常的源文件都不会那么长吧？160KB 已经可以存中长篇小说了……

[rqrq]

@ivenvd
为什么vim就不可以有算法问题啊？
很多人已经提到了windows下面几款软件处理大文件是ok的。
你认为vim没问题，那就是说打开的方式不对？

[noark9]

太大的文件，一般定位都很难吧，用文本编辑器打开来顺着编辑。。。很崩溃的感觉。。。配合下grep，awk，sed感觉应该更合适处理这些问题吧

[ivenvd]

@rqrq 很好，你成功把我的几个问题都曲解掉了。

我说的是“Vim 语法高亮算法不会有问题”，就被你曲解为“Vim 不会有算法问题”。

我说“源文件通常不会那么长”，你回避掉。

前面几位老兄虽然提到 Windows 下处理文件 OK，却没有提语法高亮的问题，而我的观点一直没有离开语法高亮，不知道你拿这些反驳我有什么意义。

我只能说，如果有编辑器能够流畅处理大文件同时开启语法高亮，那肯定也是刻意优化过这种情况，并且高亮是不完整的。而不是 Vim 高亮算法有问题。

[rqrq]

@ivenvd

quote:我说的是“Vim 语法高亮算法不会有问题”，就被你曲解为“Vim 不会有算法问题”。
我在8楼回复你，原意是编辑器的内部算法有问题。
少写了4个字，以至于让你理解为语法高亮的内部算法。
后面产生的这些口水，是因为我在8楼没说清楚，是我的错。
但是我还是想问：
为什么vim就不可以在语法高亮算法上有问题啊？

quote:我说“源文件通常不会那么长”，你回避掉。
我发这个帖子就在说源文件很长带来的性能问题，你跟我说通常不会那么长。
我说这个你说那个。

quote:“前面几位老兄虽然提到 Windows 下处理文件 OK，却没有提语法高亮的问题……”
抬杠之前麻烦你仔细看帖，我在楼顶就说了，虚拟机下的editplus处理这个css文件是ok的。
我想我不用再啰嗦这么一句吧：editplus打开代码格式的文件是有语法高亮的。

quote:“并且高亮是不完整的”
我不得不再问下你：不~完~整~是~怎~么~样~的~不~完~整~啊？