Hacker News: chrisecker

New comment by chrisecker in "Show HN: A WYSIWYG word processor in Python"

chrisecker — Fri, 10 Apr 2026 20:43:35 +0000

Ropes are for strings. In a word processor you need text with formatting, and structures as tables, images and math.

New comment by chrisecker in "Show HN: A WYSIWYG word processor in Python"

chrisecker — Fri, 10 Apr 2026 20:13:52 +0000

My mistake. Now it works (on linux).

New comment by chrisecker in "Show HN: A WYSIWYG word processor in Python"

chrisecker — Fri, 10 Apr 2026 20:10:29 +0000

My apologies. I added the missing file.

Show HN: A WYSIWYG word processor in Python

chrisecker — Fri, 10 Apr 2026 18:40:34 +0000

Hi all,

Finding a good data structure for a word processor is a difficult problem. My notebook diaries on the problem go back 25 years when I was frustrated with using Word for my diploma thesis - it was slow and unstable at that time. I ended up getting pretty hooked on the problem.

Right now I’m taking a professional break and decided to finally use the time to push these ideas further, and build MiniWord — a WYSIWYG word processor in Python.

My goal is to have a native, non-HTML-based editor that stays simple, fast, and is hackable. So far I am focusing on getting the fundamentals right. What is working yet is:

- Real WYSIWYG editing (no HTML layer, no embedded browser) with styles, images and tables.

- Clean, simple file format (human-readable, diff-friendly, git-friendly, AI-friendly)

- Markdown support

- Support for Python-plugins

Things that I found:

- B-tree structures are perfect for holding rich text data

- A simple text-based file format is incredibly useful — you can diff documents, version them, and even process them with AI tools quite naturally

What I’d love feedback on:

- Where do you see real use cases for something like this?

- What would be missing for you to take it seriously as a tool or platform?

- What kinds of plugins or extensions would actually be worth building?

Happy about any thoughts — positive or critical. Greetings

Comments URL: https://news.ycombinator.com/item?id=47722011

Points: 67

# Comments: 27

New comment by chrisecker in "TexelTree – A data model for word processors"

chrisecker — Wed, 25 Mar 2026 11:06:29 +0000

Finding a good data structure for a word processor is a difficult problem. My notebook diaries on the problem go back to 2001 when I was frustrated with using Word, which was at that time slow and unstable.

While ropes and piece tables are standard data structures, I found that an immutable n-ary tree of 'Texels' (B-Tree) works surprisingly well even in high-level languages like Python.

I’m currently taking a professional career break and decided to finally use this time to push my research further, document the results, and build MiniWord—a WYSIWYG word processor in Python.

I'd love to get your thoughts on the TexelTree. Repo/Essay: https://codeberg.org/chrisecker/texeltree

TexelTree – A data model for word processors

chrisecker — Wed, 25 Mar 2026 10:42:27 +0000

Article URL: https://codeberg.org/chrisecker/texeltree/src/branch/main/doc/essay.md

Comments URL: https://news.ycombinator.com/item?id=47515586

Points: 3

# Comments: 2

New comment by chrisecker in "Ask HN: Is there prior art for this rich text data model?"

chrisecker — Fri, 13 Mar 2026 19:40:59 +0000

You're right that hidden structure is often the cause of strange effects — but Group is not a document element in that sense. It's invisible at the index level too: when you iterate over the document by index, you pass through Groups transparently. A Group is purely a tree node for balancing purposes — it has no position in the document model that a cursor could land on, no semantic meaning, and no user-visible boundary. It has no effect the user can see or feel. Think of it like the internal nodes of a B-Tree: they exist to keep the structure efficient, but you never 'see' them when you traverse the data."

Ask HN: Is there prior art for this rich text data model?

chrisecker — Fri, 13 Mar 2026 18:22:53 +0000

I've built a rich text data model for a desktop word processor in Python, based on a persistent balanced n-ary tree with cached weights for O(log n) index translation. The document model uses only four element types: Text, Container, Single, and Group — where Group is purely structural (for balancing) and has no semantic meaning in the document. Individual elements are immutable; insert and takeout return new trees rather than mutating the old one. This guarantees that old indices remain valid as long as the old tree exists. I'm aware of Ropes, Finger Trees, and ProseMirror's flat index model. Is there prior art I should know about — specifically for rich text document models with these properties?

Comments URL: https://news.ycombinator.com/item?id=47367804

Points: 6

# Comments: 2