Modern editors are fairly complex. Splitting a bitbuffer and showing ascii line by line is simple. But modern editors have to deal with unicode, where some characters (surrogates) are two chars long, and can be followed by modifiers such as skin color of emojis. Then some characters are wider then others. So a modern editor must first parse the string encoding, then parse the language (markdown) for further formatting and coloring or building a WYSIWYG, usually on every key stroke.
The expensive part is showing the text on the screen, generating the fonts, where old editors didnt have fonts.
I'm using Typora, which works pretty well for this use case. Open source, cross-platform, very nice. I'm in no way affiliated with it, I just like it :)
I get the parsing difficulties. Generally, at least for markdown, pressing a character should affect only the line (paragraph) that contains it, so worst case scenario, you need to parse the entire paragraph. Worst case scenario, you need to re-render whatever fits on the screen. I refuse to believe it's not possible to do this efficiently with 2020 hardware, and I have proof, in the form of editors that work.
If it's 2020, I try to append a character to a 400k file I have open, and this takes multiple seconds, it's because someone implemented Schlemiel the Painter's Algorithm, not because the hardware is slow or the file is too big.
Modern editors are fairly complex. Splitting a bitbuffer and showing ascii line by line is simple. But modern editors have to deal with unicode, where some characters (surrogates) are two chars long, and can be followed by modifiers such as skin color of emojis. Then some characters are wider then others. So a modern editor must first parse the string encoding, then parse the language (markdown) for further formatting and coloring or building a WYSIWYG, usually on every key stroke. The expensive part is showing the text on the screen, generating the fonts, where old editors didnt have fonts.