On Fri, Jul 11, 2014 at 12:32 AM, Dimitris Papastamos <s...@2f30.org> wrote: > There are many ways to do this, I'd go for the simplest approach in terms of > code > readability and stop worrying about performance.
That. The reason sandy uses a double-linked list of lines is obviously not performance, but code simplicity. Sandy's performance is a joke: we memmove() the rest of the line when typing a character, allocate new memory every 128 characters or '\n' and memcpy() the whole file when matching a regexp. You can do worse than that, but you have to try really hard. Do you know what? It does not really matter. Both memory and CPU cycles are a cheap commodity these days. Most of the time you will be editing very small files. Unless you plan on having ed-like usability, the UI will take most of te CPU cycles anyway. I remember a friend came to me about editing a several megabyte XML with longish lines... and sandy did not perform as bad as I expected. Not having multi-line syntax highlighting (or XML highlighting) helped. And boy, is a linked-list convenient. Implementing text manipulation functions is a breeze. The screen painting is kinda hellish (line wrapping takes most of the fall), but it would be worse if we had to intertwine yet another data structure. Don't get me wrong. We probably need another data structure in the long run, but let's first make the editor we want and then consider the performance implications.