Show HN：一個用 Python 開發的所見即所得文字處理器

背景

MiniWord 是一款由開發者 chrisecker 耗時多年構思並以 Python 開發的極簡文書處理器。該專案的核心理念是擺脫現代編輯器過度依賴 HTML 或嵌入式瀏覽器的趨勢，轉而採用原生渲染技術，並結合 B-tree 資料結構與易於版本控制的純文字檔案格式，試圖在簡約、效能與可擴充性之間取得平衡。

社群觀點

在 Hacker News 的討論中，社群對於 MiniWord 選擇不使用瀏覽器引擎（Non-HTML）的開發路徑給予了高度肯定。許多使用者對於現代軟體動輒封裝整個瀏覽器感到疲勞，認為這種回歸原生 GUI 的嘗試令人耳目一新。特別是開發者選用 wxPython 作為工具包，引起了部分資深開發者的懷念與好奇，認為這類專案讓人想起早期 Visual Basic 或 Delphi 盛行時期，開發者熱衷於從底層構建文字編輯器或繪圖軟體的純粹感。

然而，關於文書處理器的技術實現，社群展開了深入的辯論。有留言者質疑為何不使用常見的 Rope 資料結構，作者對此回應指出，Rope 雖然適合處理純字串，但面對包含格式、表格、圖片與數學公式的富文本（Rich Text）時，B-tree 結構能提供更佳的組織能力。此外，針對 WYSIWYG（所見即所得）與 Markdown 之間的優劣，討論區出現了兩極化的看法。支持 Markdown 的用戶認為純文字格式更易於解析且不被特定軟體綁架，但反對者則指出，Markdown 在處理長篇文件、複雜表格或超連結導航時，其視覺干擾與排版限制反而降低了生產力，而一個良好的文書處理器應能自動化處理這些瑣碎的排版任務。

在功能建議方面，有資深用戶提到了 WordPerfect 時代著名的「顯示代碼」（Reveal Codes）功能。這項功能允許使用者直接查看並編輯底層的格式標記流，對於解決頑固的排版錯誤極為有效。討論者指出，Word 等軟體採用「嵌套容器」模型，導致難以實現類似功能，若 MiniWord 能在底層架構中納入這種透明性，將會是一大競爭優勢。儘管專案目前仍處於開發初期，且在 MacOS 與 Windows 平台上出現了一些路徑引用與渲染錯誤，但社群普遍對其「對 AI 友善」且「易於 Diff」的檔案格式抱持期待，認為這解決了傳統二進位文件難以進行版本管理的痛點。

延伸閱讀

在討論過程中，社群成員分享了數個與文書處理與排版相關的技術資源。針對資料結構，有人引用了維基百科關於 Rope 結構的定義；在排版系統方面，則有使用者強力推薦 Typst，這是一款專注於印刷品質且現代化的標記語言，被視為 LaTeX 的強大競爭者。此外，針對 Markdown 的進階應用，也有人提到 Pandoc 對於連結引用格式的支援，以及如 Typesetter 等側重於側邊預覽的編輯工具。對於想要深入了解 WordPerfect 格式控制邏輯的人，留言中也提供了 Corel 官方關於顯示代碼功能的知識庫連結。