BLumia
2026 年6 月 6 日 08:26
1
软件名称 菠萝记事本 Pineapple Notepad
应用平台
Windows
macOS (M系列芯片)
Linux
推荐类型 开发者自荐
一句简介 Notepad++ 的跨平台复刻/替代，作为纯文本处理的瑞士军刀，旨在在各个系统下提供与 Notepad++ 近似的交互体验。
应用简介 Pineapple Notepad （菠萝记事本）是一个 Notepad++ 的跨平台替代，在 Windows、macOS、Linux 桌面中可用。提供了包括编码转换、常用的纯文本处理操作功能、会话恢复等功能。旨在面向有 Notepad++ 使用习惯的用户提供一个跨平台的替代方案。
截图预览： 关于下载、许可 目前可以在 GitHub 与 Gitee 的 Release 页面进行下载：
你可以免费的下载和使用，不限制商业用途（详见仓库或者软件内随附的许可协议文本）。
不知道大家有没有因为早年使用 Windows 的习惯，会需要对纯文本文档进行各种各样处理的需求。我自从早年知道 Notepad++ 开始就有了一些与此软件相关的使用习惯和功能的依赖。包括显示空白字符（能显示出来 CRLF/LF，以及各种不可打印字符）、方便的文本编码识别与转换（UTF-8<->GB18030<->ShiftJIS等）、自动恢复上次会话的内容并自动恢复从未保存过的临时文档（临时记一些备忘）等，加上用它的话临时编辑一些配置文件就不需要启动那种一上来就加载一大堆插件的重型 IDE（也包括 vscode 与 zed）。
后来到了非 Windows 平台上就总是偶尔会"怀念"这些功能，或者说无法把之前的操作习惯原样带过来，就试着寻找替代方案，但发现好像很难看到类似替代。我找过一些替代，但发现或多或少有一些我自己依赖的功能它没搬上去，或者有一些奇奇怪怪的槽点。比如 NotepadNext 没有暗色主题支持，目前也完全没有实现文件编码转换的功能。后来发现的或许功能相对较全的是 Notepad–，但在后来遇到 bug 打算亲手上去修的时候才发现它实际并不开源（目前能看到的源码是一个很老的版本，无法直接编译，后续更新也都是闭源发布了）。后来实际用的比较久的是 KDE 的 Kate 但总觉得不是很习惯，再其他的替代品基本都没有在活跃维护了。甚至Notepad++ 本体也有一些槽点，每次更新都更的是一些有的没的，很少能感受到到底更了什么实质功能，真正实用的比如 Golang Kotlin QML 高亮从来都没见加过，使用自带的 Twilight 样式的话很多语言的高亮甚至会直接瞎眼到无法阅读（比如白底白字）或者完全失去高亮…
大概两年前有了这样的感受后我调研了一下相关的东西，看过 Scintilla 的接口设计后，发现如果搓这种轮子的话，会是是非常消耗精力的事情（几乎是堆工作量，技术含量相对没那么高）。现在 Agentic 编程的方案发展迅速，反倒是比较适合开坑这类项目的好机会，在比较高频率主动介入代码审核的情况下让 agent 来搓这种仿品，发现只要确保 human-in-the-loop，codereview 做的到位，效果就意外的还可以。
于是我目前开发了《菠萝记事本》Pineapple Notepad 这个软件项目，旨在为 Windows、Linux 和 macOS 用户带来 Notepad++ 风格的纯文本"瑞士军刀"编辑体验。
虽然显然目标群体是希望寻求Notepad++替代品的用户，详细而言目标是这样的：
需要轻量和快速的查看与编辑纯文本文件（不替代 IDE 的位置与功能）
便捷的文本处理功能（编码转换、行操作、空白符操作等）而不需要因这类常见但略复杂的需求去研究 sed/awk 命令
保留会话恢复之类由 Notepad++ 原版带来的使用体验
这个项目已经持续了一小段时间了，不过主动宣传并不多，所以发到这里希望如果刚巧有感兴趣的人的话可以了解下。欢迎提出建议和意见！
开源计划 如之前所提到，"AI"的发展使得开发这种业务量巨大的软件成为了可能，但无论是实际耗费精力来 review 代码与确保软件质量，还是花钱买AI订阅，都意味着这个项目本身不同于我之前的开源项目（有可能有人用过我的《菠萝看图》）需要投入更多的成本与精力。因此，这个项目目前是未开源的状态，并制定了一个开源计划：如果我能收到总计1000块的赞助的话，就将自达成目标起后的版本作为开源项目（即转为使用 OSI 认可的开源许可）发布。
这个目标截至发布此帖时大概是达成了55%，可以在ko-fi 看到进度（来自爱发电 等其他平台的赞助会延后同步更新到这个平台，因为需要手动更新进度条）。详细的开源目标说明可以在 GitHub 或者 Gitee 仓库的自述文件中看到，大致而言，对满足赞助条件的情况下，我会在关于对话框中添加赞助者的名字以表示感谢，并允许赞助者提前访问实验性/预发部版本。
我也不是很清楚开源目标何时可以达成，如果你恰巧感兴趣且有余力的话，欢迎打赏支持。
最后 这是头一次在小众软件发帖，若有不当之处还请告知
感谢各位阅读到这里，无论是否打赏之类，都欢迎给出建议、意见，或是一起展开相关讨论。
3 个赞
建议您不要用这种长篇大论式的介绍。而且，作为用户，大家更关心的是：您的软件是干什么的、有什么同类型软件不具备的优势/特点？而不是您的开发历程。
个人认为比较理想是方法，是尽量在 20 字以内就把软件最核心的特点说清楚。具体的细节，分条陈述，但不宜用过大篇幅的文字。
3 个赞
能不能兼容notepad++的插件？
不能兼容的话，说明没有意识到np++的核心护城河在哪里
BLumia
2026 年6 月 6 日 11:55
4
可能不同用户的用法还是有差异吧。比如我写这个软件的初衷就是满足我自己的需求，而我基本没有直接 用到它的插件机制。插件支持是计划在未来添加的，尽管现阶段的主要目标是先把“地基”打好。
不过更想要了解一下你的场景，比如…你是会主动编写 Notepad++ 的插件来给自己使用吗？还是说你重度依赖它的某几个第三方插件？如果是前者的话，你期望的是二进制级别的兼容还是 API 级别的兼容？
BLumia
2026 年6 月 6 日 11:55
5
感谢！最开始是不确定要投到发现频道还是讨论分享频道，看 内容提交规则（首先阅读） 有提到一句“如想要测试，请发布到 讨论分享 频道”，就按按那个频道来的。后来根据建议转到发现频道后遗漏了格式，现在重新编辑主题来按格式描述了内容并放到了最前面。
不过感觉最好也可以更新一下“内容提交规则”页面的说明，去掉“发布到 讨论分享 频道”的引导（可能是过时了？）来避免更多人误会
这个要求其实想表达的是：如果产品只是个半成品，或仅停留在设想阶段，可以发到 讨论分享
1 个赞
感谢回复，
不会编写它的插件，而是重度依赖一些第三方插件。
按照我的理解，它的核心护城河是，在本体足够轻量和兼容性足够好的情况下，有丰富的插件池可以满足各类或常见或个性化的轻度需求。
BLumia
2026 年6 月 6 日 14:43
8
不会编写它的插件，而是重度依赖一些第三方插件。
了解。
我的猜测也是大多用户不会去主动编写插件，毕竟考虑到它的插件体系也是要构建成 DLL 导出对应的 C 链接函数接口，相对别的编辑器（比如 NotepadNext）提供的类似脚本的方案而言，它的还是更复杂。
对于跨平台应用而言，二进制层面兼容它的插件方案不太现实。API 层面虽说可行，但是恐怕它的大部分插件也有平台强相关的代码，导致移植的可行性还不如干脆写新的。
而是重度依赖一些第三方插件。
另外可以描述下你重度依赖的是哪些第三方插件吗？
插件系统其实没所谓，真要说护城河只有所谓的习惯。一些第三方插件也是一样的，习惯的一部分了。
但现在毕竟所谓大模型工具这么多，不少你可以直接定制了，真正阻止你的就只有惯性了
2 个赞
kat
2026 年6 月 7 日 02:47
10
简单看了下，东西还行。但想改个主题，没法自定义。系统里就两款。我想稍微微调一下，不知道该怎么入手。
正则查找替换。这个反向引用，用什么符号？这个得告诉我，不然没法用。
BLumia
2026 年6 月 7 日 03:02
12
但想改个主题，没法自定义。系统里就两款。我想稍微微调一下，不知道该怎么入手。
主题系统后续会提供主题编辑器和自定义支持的。目前没提供是因为相关的工作方式（主要指的是如何自定义，以哪种形式提供哪些内容的配置）没完全敲定下来，如果现在提供的话后面改了用户就会很难受。没敲定的原因倒是也很简单，Notepad++的主题机制的复杂程度导致了它暗色主题稍微少提供点信息就能导致白底白字的问题，目前我的这个项目从设计上是已经避免了这个问题，但相对也少了一点点主题定制的灵活性，所以再考虑怎么权衡。
正则查找替换。这个反向引用，用什么符号？
关于正则，目前用的是 Scintilla 内置的实现（RESearch），反向引用用的是 \1 这种记法（用 \+数字）。说明文档在： SciTE Regular Expressions 。不过正则表达式的实现后续也计划调整，因为这个内置实现看上去不是很完善。对比而言，Notepad++ 用的是 Boost.Regex，NotepadNext 是 QRegularExpression。目前的 0.6.0 正则匹配零宽度也会导致卡死，这个已在 0.7.0 中修复，预计下周末前后发。
BLumia
2026 年6 月 7 日 03:07
13
真正阻止你的就只有惯性了
非常认同，完全是因为改掉习惯去适应别的 workflow 还是挺难的，不然 Kate 其实差不多就是个 UX 不太相同但功能方面非常近似的替代了。
kat
2026 年6 月 7 日 03:25
14
关于编辑器配色和正则逻辑，简单聊聊。
主题自定义我觉得非常重要，我自己用的每一个编辑器，我进去第一件事就是把配色给微调了。但这事儿得等你先把方案敲定了，我才能动。
再说正则查找替换。菠萝记事本，说实话，我极其不适应。就说一个最基本的动作，查找文本里括号，居然得让我自己去手写转义符。
VSCode：
EverEdit：
CudaText：
而菠萝记事本是这样的
菠萝记事本的正则方案，它似乎不够「主流」，反向引用符号和别的不一样，还要查找还要写转义符号。这些都在给用户增加无谓的适应负担。
一点非常不成熟的个人看法，仅供参考。
1 个赞
BLumia
2026 年6 月 7 日 03:44
15
感谢如此详尽的补充说明。
这个以两方面作为回复：
一个是，这个程序的目的首先（也是初衷）是尽可能兼容来自 Notepad++ 的用户的使用习惯，所以包括正则的转义方式也是以 Notepad++ 为基准的。你所描述的行为虽然可能合理，但是 Notepad++ 也不支持你所描述的方式来匹配括号。所以尽管我确实会考虑在后续改善正则支持，但你描述的行为也不一定会变成默认行为，而可能是放到某个设置项后面。另外其实 Notepad++ 本体也不止一个地方我觉得不符合主流交互，比如文档结构图的交互和 VSCode 比就非常奇怪之类，只是我提供的话还是会先提供和 Notepad++ 行为近似的实现，然后再逐渐提供改善。
另一个是，如之前回复你的那个描述里提到过的，正则的实现后面是会调整的，所以暂时不必特别纠结目前实现是否够主流，是否符合直觉之类。这个项目值得改进的点有很多，我也会根据来自各方（包括前面各位）的反馈来决定后面的改善方向。（只不过目前计划而言肯定是先解决之前已有赞助者反馈的问题）
总之这个反馈本身非常有帮助，再次表示感谢。
BLumia
2026 年6 月 7 日 03:52
16
不过我试了一下 vscode 里按你的描述进行操作，但是看上去 vscode 也需要转义呀？
编辑：
特地试了一下 EverEdit 也不行：
我还以为现代编辑器有什么方法可以不使用转义就能区分括号在正则里可能产生的歧义了…
kat
2026 年6 月 7 日 04:08
17
我觉得菠萝记事本的基础质感挺好，将来功能完善之后的确有可能用它，所以，我还是希望能往我的习惯方面改，那就多啰嗦几句。
虽然你一开始是要做 Notepad++的替代品，但不必被它捆死，放弃它不主流的部分，拥抱大家最习惯的那套方式，用户搬家过来的时候，不需要重新适应，这样更容易得到新用户。当然，你也提到优先支持 Notepad++ 原有特性之后，会考虑支持其他用户习惯，也算 OK 吧。
另外我又看了一下
VSCode
EverEdit
2 个赞
BLumia
2026 年6 月 7 日 05:02
18
下面的录屏清楚多了，看来我之前错误理解了原本的 use-case。你录屏所示的这个行为后续应该更换正则引擎就可以解决了，暂时预计是 0.8.0 中完成（0.7.0 已经在最终测试阶段，不会做大的调整了）。
1 个赞
感谢回复。
我个人本身插件用得不多，主要是markdown结果实时可见、markdown转出格式、MIME Tools（BASE64编解码、URL编解码等）、Favorites管理、拼写检查等。
这些只能代表我的使用习惯，如果LZ目标是要替代np++主体功能（含插件）的话，最好放大一下范围调研使用者在插件池方面的高频使用习惯。
1 个赞
BLumia
2026 年6 月 8 日 10:12
21
主要是markdown结果实时可见、markdown转出格式、MIME Tools（BASE64编解码、URL编解码等）、Favorites管理、拼写检查等。
感谢，了解
LZ目标是要替代np++主体功能（含插件）的话，最好放大一下范围调研使用者在插件池方面的高频使用习惯。
感谢建议。虽然不计划做成 100% 的 npp 复刻（没那么多时间、钱和精力。毕竟 sideproject），不过应该会尽可能至少从架构设计的角度加强可扩展性来覆盖更广的场景。这样如果哪天达成开源赞助目标，项目开源后，想做功能扩展的话项目本体就有能力支撑去做。
1 个赞
