15 ms·
1. All of them could probably easily create a bi-directional or markable stream of characters, which should be enough for the regex engine to work with. 2. Tha
by jdmichal 9y ago
1. All of them could probably easily create a bi-directional or markable stream of characters, which should be enough for the regex engine to work with.
2. That's a display issue. I would suspect that line-wrapping would want its own data structure within the display system.
3. I think this would fall under the same note as (2).
Basically, a layered approach like (display + editing mode) / (buffer) / (array or ropes or pieces or whatever). Because the editing mode would effect the edits being made to the buffer, which would then be translated into whatever underlying data structure is actually storing the file.
- abainbridge 9y agoReasonable points. As for (1), I couldn't find how to get PCRE to work with a stream like that. But that's either my fault or PCRE, not the text editor data structure. As for 2, I'd just say that I think these are much harder than the problem that the linked article discusses. There have been other articles on the same topic on Hacker News recently. They all seem to focus on solving the trivial problem and ignoring the difficult ones. I mean, a std::list<std::string> is fine for the main data structure if you just want to load, edit and save and don't require (2) or (3).
- jdmichal 9y agoI've also never seen a PCRE that actually works with such a stream, though it would be possible to construct one. For your remaining points, sure. I don't know enough about text processing to know where the hard problems are. I do think that engineers sometimes overlook the possibility of having multiple data structures for multiple use cases for a single set of data, because it doesn't seem as elegant as one magical data structure that does it all.