Re: Question collaborative editing.

[Eli Zaretskii <eliz@gnu.org>]

> From: Qiantan Hong <qhong@mit.edu>
> Date: Wed, 30 Sep 2020 15:47:04 +0000
> Cc: Ergus <spacibba@aol.com>, Fermin <fmfs@posteo.net>,
>  Jean Louis <bugs@gnu.support>, Noam Postavsky <npostavs@gmail.com>,
>  Emacs developers <emacs-devel@gnu.org>, Karl Fogel <kfogel@red-bean.com>,
>  Stefan Monnier <monnier@iro.umontreal.ca>
> 
> 
> [1:text/plain Hide]
> 
> >> 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.
> >> 
> >> 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.
> > 
> > I'm probably missing something because I don't understand the problem
> > that worries you.  Given the information about how to update a buffer,
> > isn't it relatively easy to generate a series of insert/delete/replace
> > operations from that information?  And if so, those actions can be
> > almost trivially converted to Emacs primitives that manipulate buffer
> > text.  What am I missing?
> I was just thinking in general, keeping several copy of data and trying 
> to get in sync is a likely source of bug and maintenance problems. 
> Suppose there are some bug in the implementation and the CRDT lose
> track of some part of the text. If CRDT is attached to Emacs buffer, all
> operation will still operate almost correctly and resolve to the
> correct intents — because they are item based rather than buffer
> position based. Suppose it’s implemented in C library way and C
> library communicate to Emacs via buffer position information —
> the extra text will make the position off and completely mess up
> any further operation on this buffer.

That's the problem collaborative editing needs to solve, isn't it?
The communications between clients should allow resolution of
differences in buffer position, and detection of losing track of text
modifications.

I don't yet see how the need to solve this problems would require
working on the lowest level of the buffer-text implementation.

> Also this scenario doesn’t necessarily comes from a bug in CRDT
> implementation — there’s inhibit-modification-hooks which may
> prevent some changes to be told to the C library.

You don't need buffer-modification hooks, you can use other existing
mechanisms.  Emacs knows that buffer text was changed even if the
modification hooks were inhibited.

> I agree that there’s no problem with C library if everything behaves
> well — I don’t like the idea of keeping two replicate of data to keep
> in sync (the whole CRDT is to solve this) but it might be my personal
> opinion.

I don't think I understand what you mean by "C library" here.