Re: Question collaborative editing.

[Ergus]

On Tue, Sep 29, 2020 at 11:40:53PM +0000, Qiantan Hong wrote:
> > In the library level we could (and maybe should) implement both (OT and
> > CRDT). This will only require a hint from the server side (or the
> > connection starter client) to inform the client's libraries "what to use
> > this time". Then practice will say what's better.
> >
> > ATM we could start with a C library in order to provide a nice free
> > back-end editor agnostic. Because IMO the most interesting part of this
> > will be to open emacs to interact with other editors with a free
> > infrastructure emacs-centric.
>
> I’m not sure if it’s easy (or worth the effort) to provide CRDT in an
> editor-agnostic way from C-level. Seems that the most natural
> choice is to tag characters with CRDT data structures. Emacs has
> text property which is very suitable for this, and I’m implementing
> it in this way as an Elisp library. However, this relies on the particular
> data structure for buffer/text emacs uses.
Oh; I get it.

I would be concerned about the performance (but I am paranoid about
Emacs performance anyway so don't worry for that). AFAIR emacs buffers
are stored in a contiguous way (I may be wrong) and in that case the
search with CRDT may be expensive. At least as it was explained here (in
the optimization section):

https://conclave-team.github.io/conclave-site/

Unless some extra optimizations are implemented of course.

> If implemented as a separate C library, I imagine the CRDT library
> need to have its own buffer/text data structure and somehow keep
> in sync with Emacs’ .. doesn’t sound so clean.

Agree. That was exactly my idea. Keep all that in the library and emacs
just processes the final translated outputs with absolute char positions
from the json.

I took Tandem as the starting point in my considerations... But you may
be right. If it is easier to implement and works; it may be fine and
simpler than what I had in mind.

Best,
Ergus