Three dominant themes
| Theme | What the discussion says | Representative quotes |
|---|---|---|
| Home‑grown editors & modularity | Many users proudly build or heavily tweak their own editors, seeing it as a way to get exactly what they need. The idea of piecing an editor together from task‑specific executables is also discussed. | “I use my own text editor too.” – codazoda “I’m currently writing my own text editor (it’s basically a markdown equivalent of Jupyter notebooks).” – hnlmorg “I want one step up. I want to be able to piece together an editor from modular task specific executables.” – willrshansen |
| Performance & latency of modern editors | Users compare lightweight, native editors (Acme, Kate, Zed, Helix) with heavy Electron/VSCode setups, noting that the latter can feel sluggish, especially on older hardware or with large files. | “Firing up VSCode on an old laptop, and having it get totally bogged down.” – fragmede “I am always surprised even vim chokes on files with one massive line.” – mejutoco “I don't notice any sluggishness.” – roelschroeven |
| Simplicity, learning, and the cost of modularity | Building an editor is praised as a learning exercise that forces developers to focus on core concepts, avoid unnecessary modular splits, and keep code lean. | “Software is simpler than you think when you boil it down.” – zesterer “Delete code, often.” – zesterer “Aggressively chase simplicity and avoid modularity if you want to actually achieve anything.” – zesterer |
These three threads—personal editor construction, the trade‑off between speed and feature‑richness, and the philosophy of keeping software simple—capture the heart of the conversation.