文本编辑器:Text Edit Plus、filter过滤、Vim、AI Coding……
-
有安装版,亦有便捷版,都很小巧,5MB左右。(好) -
有试用期,正常价格 $19,当前有限免。 -
开发者有几十款小巧的工具软件,freeware + shareware,涉及pdf、文本、图片、笔记、编程、下载、系统…… (看来作品质量或推广不好,以前没太听说。现在这个时代,就更没有市场了) -
本编辑器,基于 SynEdit 内核——准确讲,是可以在 SynEdit 和 系统默认内核间切换,前者功能更多。


-
中文编码识别不是特别好。很不幸,我第一个打开的文件是冰凌输入法词库,用了罕见的 UTF-16LE BOM 编码,未能识别,亦未能手工切换。 -
换了 GBK ANSI 编码的「倚天屠龙记」,正常打开,但有明显加载过程。软件显示,加载用了0.8s。此期间我用滚轮缩放字体,明显卡顿。但加载完成后,再缩放字体,比较流畅。 -
支持调整行距。 -
找了半天,终于找到了「过滤」。入口功能看,比较强大: 
-
但使用体验不太好:不支持关键词的高亮。 -
多关键词过滤,是支持的。但需要分两步操作,体验不佳。上述结果,就是先过滤“小说”,再过滤“读者”的效果。
-
我先总体试探:有过滤功能的Windows免费编辑器?Gemini回答了 NotePad++, Sublime, VSC, Vim。没有错误,也没有惊喜。 -
再进一步试探:还有一些更小众的软件,请全部列举。Gemini答复有:EmEditor (Free / Pro)、EverEdit、EditPlus、AkelPad、Vovsoft Text Filter……等。前几款我知道;AkelPad我印象中无此功能;Vovsoft Text Filter 是本文提及的 Text Edit Plus 的同门产品(说明Gemini还是有功力的) -
按Gemini所说的 AkelPad,「需要确保安装了官方的 LineBoard 或 Log 扩展插件,通过在搜索框输入指令,可以直接隐藏不匹配的行,或者将匹配行高亮分离。」我去查看对应插件的说明,明显感觉不对。再对质,AI认错。 
所以,在人类知识的边缘领域,AI对专注问题多年的专家,主动帮助不大(但可以起到低成本核查、校验之作用)。
-
以前,我使用搜索引擎,来寻找工具。 -
今天进了一步:使用AI,比搜索引擎更快捷、更全面(未必更全面)寻找。但从结果看,并没有新发现。 -
但是,AI 不应该局限于此,应该再向前,再多进一步:AI coding ,创造工具。
-
用户提出:询问 Windows 平台上有哪些免费的文本编辑器支持“行过滤(Filter Lines)”功能(例如只显示包含
keyword-A的行)。 -
AI 建议:推荐了主流的 Notepad++、Sublime Text、VS Code 以及小众的 EmEditor、CudaText 等,并详细指出了各自的实现手法。
-
用户发现并纠错:非常细致地指出 AI 之前提到的轻量编辑器 AkelPad 及其插件简介中并未发现过滤功能。
-
AI 修正:承认并纠正了关于 AkelPad 的记忆混淆,明确其 LineBoard 和 Log 插件的真实用途,并指出要在 AkelPad 中实现过滤必须依赖其他高级检索插件或复杂的破坏性脚本。同时,AI 补充说明了最完美的 EmEditor 过滤功能在免费版中是被官方锁定的。
-
用户提出新思路:既然免费软件各有遗憾,是否可以用 Python 自己写一个简单的文本查看器(Viewer),来模仿 EmEditor 那种动态、流畅、不破坏原文本的过滤功能?
-
AI 建议并提供初版代码:认为完全可行。利用 Python 自带的 Tkinter 库,通过“内存数据源”与“界面显示”分离的逻辑,写出了一个利用
Listbox控件“打字即过滤”的极简原型。 -
用户追问性能:关心这个初版代码在普通 Windows 11 笔记本上,处理 10MB 的中文小说(约十几万到几十万行)时,性能是否吃得消。
-
AI 进行性能剖析:指出 10MB 文本在内存中完全不卡,但核心痛点在于渲染——如果每打一个字就让图形界面重复销毁并重新插入几十万行,会导致严重卡顿和打字粘滞。
为了解决这个痛点,AI 提出了“两层性能优化取舍”:
-
引入“渲染切片(虚拟视窗)”: 界面最多只渲染前 2000 行。人眼看不出区别,但渲染性能直接暴涨 100 倍。
-
引入“0.5秒防抖机制”: 避免用户打字过程中产生频繁的无效计算。 同时,AI 提出如果想支持单字局部高亮,底层必须从
Listbox控件升级为Text控件。 -
用户明确需求,并尝试拓展功能:认可了防抖和切片优化。同时敏锐地察觉到,既然底层换成了功能更强的
Text控件,是否可以顺便实现修改文字、添加新行等简易编辑功能? -
AI 深度剖析“数据断层”逻辑难题:指出在“行过滤”状态下直接进行普通编辑会引发致命 Bug:由于过滤后的行被重组,界面上的“第 2 行”无法对应原文件 10 万行里的真实位置,一旦保存会导致数据大面积丢失。
为了在保持 Viewer 极致流畅的前提下实现编辑,AI 提出了功能实现思路的演进:
-
思路一: 仅支持单行双击弹窗修改,利用内容匹配同步原内存(缺点是无法处理内容重复的行,且无法增删)。
-
思路二(极客解法):带行号渲染(行号隐式绑定指针)。在过滤和显示时,强行让每一行文本在行首死死绑定它在原文件中的“绝对行号”(例如
[005421])。双击时通过解析行首行号,直接对原文件内存实施精准的“微创手术式”修改。 -
用户最终拍板,做最后的性能与功能取舍:做出了非常务实、聪明的剪裁决策:
-
保留行号显示(因为这些信息本来就对查看日志/小说有用)。
-
功能做减法,保持简单: 只要“单行编辑(修改)”,完全放弃删除或添加行的复杂功能。
-
视觉与系统适配优化: 指定高档的“微软雅黑 Mono,14号”字体,并要求必须完美支持 Windows 11 的高分屏 DPI 缩放,防止界面模糊。
-
最后实现的功能:AI 交付了最终的生产力工具代码。通过“防抖 + 渲染切片 + 行号指针映射”的精妙组合,在区区不到 200 行的 Python 原生代码里,完美实现了:
-
在 Windows 11 高分屏下极其清晰锐利、不模糊的界面。
-
处理 10MB+ 大文件时,打字毫无粘滞感、0.5秒精准触发的流式多关键词独立颜色高亮过滤。
-
安全的单行双击微调编辑:双击即可修改任意匹配行,并能完美、精准地同步回内存中的原文件。

N天没写公众号了,今天既然有随想随做,也就随手记录一下。但要说明的是,这些折腾的细节过程和成果(尤其是成果),也并无太多价值。更有价值的,是从一则材料感受到问题,再引发好奇心,再转为尝试的行动力;以及在试错/研究过程中,识别信息与形势,找出突破路径的能力。
另:「并无太多价值」,只是基于较高标准而言。在我的价值观中——也如我在微信群多次强调——任何一手实证的记录,无论再低级,甚至错误,也比「廉价的正确」更有价值。知识的源头是实践,终点又是指导实践;AI擅长推理总结,但缺乏实践创造。从阅读来看,在枯燥的“爱迪生实验记录:xx材料电灯丝实验(失败)” 与 十万加的“最适合电灯丝的5种材料,第5种你万万想不到”之间,我肯定支持前者。
夜雨聆风