Architecture-wise, you can start with an ordered list of lines, with each line stored as a string.
Features that complicate things are:
- supporting large documents and staying speedy (“replace all” is a good test case)
- supporting line wrapping or proportional fonts (makes it harder to translate between screen locations and (line, character) offsets)
- supporting Unicode (makes it harder to translate between screen locations and (line, byte position) offsets)
- syntax-colouring
- plug-ins
- regular expression based search (fairly simple for single-line search _if_ you store each line as a string; harder for custom data structures, as you can’t just use a regexp library)
- supporting larger-than-memory files (especially on systems without virtual memory, but I think that’s somewhat of a lost art)
- safely saving documents even if the disk doesn’t have space for two files (a lost art. Might not even have been fully solved, ever)
Architecture-wise, you can start with an ordered list of lines, with each line stored as a string.
Features that complicate things are:
- supporting large documents and staying speedy (“replace all” is a good test case)
- supporting line wrapping or proportional fonts (makes it harder to translate between screen locations and (line, character) offsets)
- supporting Unicode (makes it harder to translate between screen locations and (line, byte position) offsets)
- syntax-colouring
- plug-ins
- regular expression based search (fairly simple for single-line search _if_ you store each line as a string; harder for custom data structures, as you can’t just use a regexp library)
- supporting larger-than-memory files (especially on systems without virtual memory, but I think that’s somewhat of a lost art)
- safely saving documents even if the disk doesn’t have space for two files (a lost art. Might not even have been fully solved, ever)
Edit: you also want to look at https://news.ycombinator.com/item?id=11244103, discussing https://ecc-comp.blogspot.com/2015/05/a-brief-glance-at-how-...