Re: Future of display engine and lines

[Eli Zaretskii]

> From: chad <yandros@gmail.com>
> Date: Tue, 9 Nov 2021 15:13:28 -0800
> Cc: Richard Stallman <rms@gnu.org>, Eli Zaretskii <eliz@gnu.org>, Lars 
> Ingebrigtsen <larsi@gnus.org>, 
>       EMACS development team <emacs-devel@gnu.org>
> 
>  The question is not to have multiple gaps (although that would actually be 
>  useful for some extensions like multiple-cursors (which btw is pretty nice 
>  and emacs is the only editor to support that)), 
> 
> I think I might misunderstand you, because, if I recall correctly, Emacs' 
> multiple-cursor support is a port of
> the concept from Atom, which borrowed it from Sublime Text. In any case, at 
> this point multiple-cursor
> support (perhaps under varying names) exists in several commonly used 
> editors, including gedit and
> vscode.

In any case, I don't think multiple-cursors have necessarily anything
to do with the way we store and process buffer text.  It's a display
feature, not necessarily a text-editing feature.

>  In principle there might be a more efficient representation of
>  buffers.  But I am skeptical about that.  When I tried to look for a
>  better representation that would allow for multiple gaps, I couldn't
>  see a good answer about how to use them and gain any benefits.
> 
> It's been a few years since I last looked at this, but if anyone is 
> {seriously,academically} interested in
> changing Emacs' underlying buffer representation, I recommend looking closely 
> at ropes:
> 
>   https://en.wikipedia.org/wiki/Rope_(data_structure) 
>  
> I've been away from these academic circles for a while now, so it's possible 
> that this recommendation is out
> of date; I would love to see (a pointer to) an update if anyone has such a 
> thing.

I think if we ever seriously consider changing the representation of
buffer text, we should consider first what will benefit faster display
operations, not the efficiency of insertions and deletions.  Because
without well-known display problems, we won't have a good enough
reason to change the buffer text representation in the first place.
And it must be a very good reason, because the job of changing that
representation is not a trivial one.