You might not open a large file in common usage but when you need to open a large log the issue is not negotiable. If anything the Rope data structure is to text editors as the B-Tree is to file systems.
Memory mapping the file doesn't really help an editor much. For one thing you can't have your buffer changing arbitrarily underneath your parse of it.
But also in order to have both precise and fast scrolling, especially when syntax highlighting or line wrap is involved (usually you don't want both but you might want one or the other), you need to do at least a superficial parse on the whole thing anyway.
Op here, I absolutely agree on the log file issue. But also believe that people underestimate the size of files. Yes, code is rarely that big, but you don't want your editor crawling, because you open some tool or languages build log by mistake.
I remember some guys in the #vim irc channel a couple years back discussing an editor that used ropes in the text store. I believe they said using lua, and that it's really performant. I don't know what happened to that, but for some reason I always thought that it eventually turned into sublime, but I've never really used sublime besides basic usage, so I can't really comment on its performance.
The irony is that I remember people complaining about how slow vim is for large files. Nowadays compared to the alternatives it seems to be blazing fast.
All of which can be done with less? It really doesn't make sense to load up a large file in a text editor and parse the syntax and such if it isn't going to be edited. There are already very good tools for text reading.
