[rstat1]

I believe VSCode's editor is actually built on a variation of a piece table (they call it a piece tree)

https://code.visualstudio.com/blogs/2018/03/23/text-buffer-r...

Not sure if this is still the case, but it was as of 2018.

Its really kind of fascinating to me, all the different ways we've come up with over the years just to manipulate text.

[vidarh]

> Its really kind of fascinating to me, all the different ways we've come up with over the years just to manipulate text.

One of the things that strikes me is how much effort goes into making these editors work well with absurdly large files, rather than more editors punting on that and having people fall back on specific tools for huge files.

For my own editor I basically decided to ignore large files entirely and fall back on using emacs for the very rare case where I need to open an absurdly large file.

I know that's a luxury Jetbrains doesn't have, because we've come to expect all editors to handle ridiculous sized files well.

But the point being that for reasonably sized files - up to tens of thousands of lines - just an array of strings is more than fast enough.

Even with an editor like my personal one (not really usable for anyone else, though I've started packaging up parts of the code) written in Ruby (which introduces a substantial overhead per string).

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

[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.