Re: Gap buffer problem?

[Gerd Möllmann]

Dmitry Gutov <dmitry@gutov.dev> writes:

> On 12/12/2024 05:49, Gerd Möllmann wrote:
>
>> The Zed editor, which is heavily performance-oriented, decided to use
>> ropes. They have are a number of blog entries that I find interesting,
>> for example
>>    https://zed.dev/blog/zed-decoded-rope-sumtree
>
> IIUC their goal there was a use a data structure that can do everything.
>
> They also have an ambition to support live collaboration, which we
> don't have anything for, and not for the reasons of performance.

I don't find it surprising that being fast isn't the only requirement
for a modern editor, TBH. Thing is that from what I observe, Zed seems
to have no problem with long lines. But maybe that's a wrong
observation. I never did anything that required long-line support.

Point I was trying to make is that apparently ropes can support long
lines. One could maybe learn from what they do; Rust sources are
available, Of course, additional data structures like ones to make
positions to actual text and so on belong into the picture. It not just
using ropes, but in this case the rope is the basic data structure, and
additional data structures depend on the properties of that.

>
>> VSCode uses persistent piece tables
>>    
>> https://code.visualstudio.com/blogs/2018/03/23/text-buffer-reimplementation
>
> And this article compared to the previous "array of strings" implementation.
>

And shows that they are using piece tables, the alternative to ropes, if
one doesn't count the other two which are gap buffer and set of lines
for the moment. And I think they got long-lines support working, too.
And again there are additional data structure involved, and blah blah.

> Both editors' data structures (not ropes) seem to have something that
> can be used like our "newline cache", so if anything I would try to
> understand whether either has an advantage in that area.

For me that would be a too narrow perspective, I must admit. But I won't
do anything in that area anyway, so please ignore me :-).