[Ygg2]

> I think if I ever decide to make my editor handle really huge files, I'll "just" split them in suitably large chunks and lazily do the necessary processing as needed

That falls apart the moment you need some non-basic feature like matching open/closed brackets/elements, etc.

Or references. Or refactoring ...

[vidarh]

I think that missed my point. If a file is large enough that this becomes an issue, it is tens of thousands of lines or more, which means it's rarely human written code. I'm perfectly happy to turn off anything fancy in that scenario, as on the rare (every few months at most) occasions where I open such monstrously large files it's usually a log file or similar, not code. Your mileage may well vary, but I'm not interested in writing a general purpose editor (some components of my editor are general purpose, and I'm packaging up some of them, but the editor itself is written entirely with my own usage patterns in mind - my editor is smaller than my .emacs file used to be). I think more people ought to focus on writing more opinionated editors rather than try to make everyone happy.

That said, it's not true that it needs to affect features like the ones you mentioned - all you need is to add a facade that gives your tools whatever interface to the buffer they need. As it is, my editor stores its buffer in a separate server process, because it was trivial to do so and gave me a bunch of benefits like multiple clients connecting to the same buffer, which also means I can trivially have out-of-process services augmenting the buffers with additional state lazily without needing to know anything about how the buffers are represented. The server process + a facade for the current buffer implementation + most of the basic editing operations the rest is built on is ~500 lines of code.