如果您复制我在下面的链接中提供的文字并将其粘贴到文本编辑器中（我尝试了几个文本：gedit，notepad，phpstorm，还有命令行像nano这样的编辑，你会遇到困难。
以下是我在测试期间注意到的一些内容：
我还注意到，如果我在相应的文本编辑器中启用text-wrap功能，则会出现 not 这些问题。
我想知道的是，为什么文本编辑器有长线的这类问题？对这种行为有合理的解释吗？
答案 0 :(得分：5)
我想知道的是，为什么文本编辑器会出现这种长线问题？对这种行为有合理的解释吗？
我是Zeus IDE的作者，所以我会考虑为什么会出现这种情况。
一个主要原因是制表符的存在。让我解释一下。
因为文本编辑器必须假定该行可能包含制表符，所以它能够正确处理这些制表符的唯一方法是从左到右解析该行，始终从该行的第一个字符开始。
要理解原因，请考虑以下两行代码，其中^表示制表符：
This is line one with no tables
This line has a ^ tab character
如果标签大小为8，则需要按如下方式绘制：
This is line one with no tables
This line has a tab character
如果标签大小为4，它将如下所示：
This is line one with no tables
This line has a tab character
但这两行的长度完全相同，只有31个字符。
因此要正确绘制线条，编辑器必须从左到右解析线条，始终从线条的第一个字符开始。
当然，对于长线来说，这种绘图可能很慢。
现在考虑第二种情况，其中| character代表光标：
This is line one with no |tables
This line has a tab character
在上面的情况中，光标位于行中的索引位置25，这也表示屏幕上的光标位置25（因为该行不包含制表符）。
现在让我们假设用户将光标向下移动一行，如下所示：
This is line one with no tables
This line has a |tab character
现在光标仍处于光标屏幕位置25，但由于8字符制表符代表该行的索引18位置。
为了解决这个问题，编辑器需要在线路上运行计算检查沿途的标签，再次为长线需要时间。
这些只是游标索引的两个例子，光标到索引映射需要由编辑器完成。
键盘事件，鼠标点击，文本标记，文本剪切/复制和粘贴等也需要相同的计算。
我还注意到，如果我在相应的文本编辑器中启用了文本换行功能，那么这些问题就不会发生。
当你打开文本换行时，你已经有效地占用了一条长行，并将它变成了许多较短的行，这反过来加快了前面提到的标签计算。
PS：Zeus确实处理了你的286,721个字符行，但是和大多数编辑一样，它对那个行长的文件反应不佳。