🪩 Provide a link to the proposed addition
https://mr-tabata.github.io/MrEditor/
https://github.com/MR-TABATA/MrEditor
😳 Explain why it should be added
Correction (2026-07-12). I originally filed this issue with a memory figure of "44 MB",
and with a first-paint time of "~210 ms" and an index time of "~20 s". Those came from a
benchmark run on a pre-1.0 build and I reused them without re-measuring. I have re-measured
everything on the shipping 1.0.2 release build and corrected the numbers below. The speed
figures were wrong in my favour by ~2–3x (it is faster), and the memory figure was wrong
against me: the app's footprint is 162 MB, not 44 MB. I would rather fix it here than
have you find it.
MrEditor is a Mac-native (AppKit, no Electron) text editor built for the files other editors refuse: it opens a 10 GB log — 86,420,337 lines — in 65–83 ms, holds 0 bytes of that file in memory (it is mmap'd, never copied — vmmap reports 0 dirty bytes for the mapping), and edits and saves it in place with atomic writes.
It is MIT-licensed, free, universal (Apple Silicon + Intel), signed with an Apple Developer ID and notarized, so it opens with a plain double-click. macOS 13+.
Why it earns a line in the list:
- It fills a real gap in Text Editors.
NSTextView keeps the whole document in NSTextStorage, so every editor built on it falls over at gigabyte scale. Nothing currently in the section handles multi-gigabyte files; the tools that come close (klogg, lnav) are read-only log viewers and are not Mac-native. MrEditor mmaps the file, keeps a sparse line index, draws only the visible lines with Core Text, and represents edits as a piece table — so inserting a character at line 1 of a 10 GB file does not rewrite 10 GB.
- It edits, not just views. Full-file search, regex, filtered view (live grep) and
tail -f follow, plus a structured view (CSV/TSV column alignment, NDJSON field projection).
- It is genuinely CJK-first. IME input in the editor, encoding detection, Shift_JIS / EUC-JP conversion on save, CRLF/CR/LF handling — unusual for this category, and relevant to a good part of this list's readership.
Honest limitations, since I'd rather you hear them from me: the 80 ms is time to first paint. The full line index of that 10 GB file takes about 9 seconds; it builds in the background and never blocks the view, but the exact line count and full-file search only settle once it finishes. While indexing, ps RSS climbs to several GB — that is reclaimable, file-backed mmap page cache, not resident app memory (vmmap reports 0 dirty bytes for it) — but it does look alarming in Activity Monitor. The app's own 162 MB footprint is window backing store and the kernel page tables for a 10 GB mapping, not your log. The app is also young: 1.0 shipped 2026-07-11.
I am the author.
📖 Additional context
Proposed entry for Reading and Writing Tools > Text Editors, in the existing style of the section (alphabetically between micro and Neovim):
* [MrEditor](https://mr-tabata.github.io/MrEditor/) - "A Mac-native viewer — and editor — for 10 GB text files." [![Open-Source Software][OSS Icon]](https://github.com/MR-TABATA/MrEditor) ![Freeware][Freeware Icon]
A 10 GB, 86,420,337-line log open in MrEditor:
Measured on a 10.00 GB / 86,420,337-line Japanese UTF-8 log, on the shipping universal release build (2026-07-12):
| Metric |
Result |
| Time to first paint |
65–83 ms |
| The file's own pages |
4.2 GB resident, 0 bytes dirty |
| App physical footprint |
162 MB with the file open (32 MB with nothing open) |
| Seek to last line |
0.1 ms |
| Full background index |
~9 s (does not block display) |
| Full-file search |
4.59 M hits |
Read the middle two rows together: the 10 GB costs nothing (mapped, not copied, 0 dirty bytes), and the 162 MB the app does use is window buffers and page tables — not the file. Reproduce it with:
MREDITOR_TIMING=1 MrEditor.app/Contents/MacOS/MrEditor big.log # → first paint: 81.3 ms
vmmap $(pgrep -x MrEditor) | grep big.log # → 10.0G 4.2G 0K
Benchmark table and more screenshots: https://github.com/MR-TABATA/MrEditor#performance
Happy to open the PR myself and update README.md, README-zh.md, README-ja.md and README-ko.md together if you'd prefer that — just say the word. Japanese description, if useful: "10GB のテキストファイルを開いて編集できる、Mac ネイティブのエディタ。"
🧨 Issue Checklist
🪩 Provide a link to the proposed addition
https://mr-tabata.github.io/MrEditor/
https://github.com/MR-TABATA/MrEditor
😳 Explain why it should be added
MrEditor is a Mac-native (AppKit, no Electron) text editor built for the files other editors refuse: it opens a 10 GB log — 86,420,337 lines — in 65–83 ms, holds 0 bytes of that file in memory (it is mmap'd, never copied —
vmmapreports 0 dirty bytes for the mapping), and edits and saves it in place with atomic writes.It is MIT-licensed, free, universal (Apple Silicon + Intel), signed with an Apple Developer ID and notarized, so it opens with a plain double-click. macOS 13+.
Why it earns a line in the list:
NSTextViewkeeps the whole document inNSTextStorage, so every editor built on it falls over at gigabyte scale. Nothing currently in the section handles multi-gigabyte files; the tools that come close (klogg, lnav) are read-only log viewers and are not Mac-native. MrEditor mmaps the file, keeps a sparse line index, draws only the visible lines with Core Text, and represents edits as a piece table — so inserting a character at line 1 of a 10 GB file does not rewrite 10 GB.tail -ffollow, plus a structured view (CSV/TSV column alignment, NDJSON field projection).Honest limitations, since I'd rather you hear them from me: the 80 ms is time to first paint. The full line index of that 10 GB file takes about 9 seconds; it builds in the background and never blocks the view, but the exact line count and full-file search only settle once it finishes. While indexing,
psRSS climbs to several GB — that is reclaimable, file-backed mmap page cache, not resident app memory (vmmapreports 0 dirty bytes for it) — but it does look alarming in Activity Monitor. The app's own 162 MB footprint is window backing store and the kernel page tables for a 10 GB mapping, not your log. The app is also young: 1.0 shipped 2026-07-11.I am the author.
📖 Additional context
Proposed entry for Reading and Writing Tools > Text Editors, in the existing style of the section (alphabetically between
microandNeovim):A 10 GB, 86,420,337-line log open in MrEditor:
Measured on a 10.00 GB / 86,420,337-line Japanese UTF-8 log, on the shipping universal release build (2026-07-12):
Read the middle two rows together: the 10 GB costs nothing (mapped, not copied, 0 dirty bytes), and the 162 MB the app does use is window buffers and page tables — not the file. Reproduce it with:
Benchmark table and more screenshots: https://github.com/MR-TABATA/MrEditor#performance
Happy to open the PR myself and update
README.md,README-zh.md,README-ja.mdandREADME-ko.mdtogether if you'd prefer that — just say the word. Japanese description, if useful:"10GB のテキストファイルを開いて編集できる、Mac ネイティブのエディタ。"🧨 Issue Checklist