Re: Question collaborative editing - Wikipedia reference

[Qiantan Hong]

> 
> All this leads to some possible feature requests for crdt.
> 
> (1) Would it make sense for a future version of crdt.el to also manage a list 
> of files (like Projectile or Gobby?).  
> (2) Would it make sense for a future version of crdt.el to sync not just 
> buffers... but also commands and windows (like lockstep?)
> 
Yes, I think both make perfect sense. 
For 1, if it’s to be implemented separately I’ll have to think about the right 
model.
One end of the spectrum is to have a built-in file manager — the other end
is to just provide some command like M-x crdt-goto-this-buffer to allow taking
a CRDT session to the buffer with another file.

I personally thought more about 2, and I concluded that supporting arbitrary 
command
in general is almost impossible (given that we want to apply command in real 
time, and
eventual consistency). When one site invoke a command X that depends on a chunk 
of text, 
some other site might mutate the text at the same time, or invoking some 
command that
interfere with X — and without any knowledge of how the command works it’s 
impossible
to solve this general problem.

However, I do think it’s possible to make other Emacs packages 
realtime-collaboration-complaint
with relatively little effort if I provide the right infrastructure. Emacs 
applications are in general
built around buffer, and by just syncing buffer text, text properties, markers 
and overlays using CRDT,
those without using any variables will work automatically — with eventual 
consistency guarantee!
Then I might provide some distributed version of DEFVARs for 
buffer-local-varaibles —
def-crdt-counter etc, or some non-realtime def-server-var — with a few 
annotation a single-Emacs
package should be able to be adapted to collaborative use.

I’m very excited by this idea, I might call it “Emacs as a distributed (or 
collaborative) OS”.

smime.p7s
Description: S/MIME cryptographic signature