打开包含不太长行的文件时会显示此消息。当然，当文件包含非常长的行时会显示此消息。但我想阻止此弹出消息出现。我知道它可能会影响性能，但我想摆脱它只是一次额外的点击。
答案1
这是我在 Unix 和 Linux 上发布的有关类似问题的答案的副本，标题为：如何消除 Bluefish 中的“分割线”错误？。我将其发布在这里，因为我发布的票据（如下所述）所驱动的解决方案可能会为两者带来潜在的解决方案。
听起来类似的错误？
不确定这个问题是否相关，但如果你在 Bluefish bugzilla 问题跟踪器中查看此问题的详细信息。该问题的标题是：线路很长并且 CPU 使用率很高，这听起来没什么关联，但如果你看一下这个问题：
摘抄
我已经使用基于 gtk+-2.24.17 构建的 bluefish 2.2.2 进行了测试，后来又基于 gtk+-3.4.4 进行了测试，得到了相同的行为。
我做了很多 css 编辑，不久前我发现 base64 图像存在问题。而且图像越大，问题就越严重。
base64 图像可能会导致行非常长，即使是小图像也是如此，因为位图信息必须使用 ascii 子集（或其他任何子集）进行存储。因此，我最终得到的行有 +10,000 列，有时甚至更长，这并不奇怪。
当我向下滚动这样的文件时，就在有问题的行即将出现时，编辑器冻结了，我可以看到 gkrellm 对 CPU 使用率感到愤怒。我可以在 nano 中打开同一个文件并随意滚动，甚至不会注意到 CPU 峰值。
当 CSS 文件充满这些内容时，我只需关闭 bluefish 并使用手头上的任何内容即可。
其中一位开发人员发表了这样的评论：
感谢您的报告，不幸的是，这是 gtk textview 小部件中的一个已知错误。
Bugzilla 中某处有 gtk 的错误报告，但多年来一直未修复。我很惊讶 Windows 版本没有这个问题，它也使用 gtk……
我知道您看到的错误听起来不同，但这两个问题似乎与我有关。我建议将此问题记录为错误，并查看开发人员
关于此问题的开放问题
为了尝试帮助您和 U&L 上的其他 OP 加快解决此问题，我将此问题作为 Bluefish 项目的 Bugzilla 中的一个错误提交。
请随意发表评论，希望我们能很快听到有关此问题的消息。