From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Question collaborative editing. Date: Wed, 30 Sep 2020 16:43:33 +0300 Message-ID: <83a6x7js6y.fsf@gnu.org> References: <20200924013655.asv2tem25cbwv5et@Ergus> <2ACED303-9A2C-4363-BE56-2E9AF0B8DC85@posteo.net> <20200925002239.fgg3vw2nylltcoyp@Ergus> <219042AC-556D-48CC-8920-82D9BF2BD3AA@aol.com> <3A81FB67-A558-4281-8285-CDD9B01033E3@posteo.net> <1C949FC9-6023-467E-99EC-75D57B08AFB0@gnu.support> <20200929124513.fd745r2txowwbiir@Ergus> <87blho7af9.fsf@red-bean.com> <20200929215849.zg4wzytbrwx2b7ih@Ergus> <84B86B7C-81F0-42DF-894C-BF577E4B3D6E@mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5890"; mail-complaints-to="usenet@ciao.gmane.io" Cc: spacibba@aol.com, fmfs@posteo.net, bugs@gnu.support, npostavs@gmail.com, emacs-devel@gnu.org, kfogel@red-bean.com, monnier@iro.umontreal.ca To: Qiantan Hong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Sep 30 15:56:23 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kNcah-0001Fs-PB for ged-emacs-devel@m.gmane-mx.org; Wed, 30 Sep 2020 15:56:19 +0200 Original-Received: from localhost ([::1]:47446 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kNcag-0005Q0-PK for ged-emacs-devel@m.gmane-mx.org; Wed, 30 Sep 2020 09:56:18 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38720) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kNcOZ-0008BD-EK for emacs-devel@gnu.org; Wed, 30 Sep 2020 09:43:51 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:33493) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kNcOW-0005qo-4X; Wed, 30 Sep 2020 09:43:44 -0400 Original-Received: from [176.228.60.248] (port=1180 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kNcOU-0000hO-Qc; Wed, 30 Sep 2020 09:43:43 -0400 In-Reply-To: <84B86B7C-81F0-42DF-894C-BF577E4B3D6E@mit.edu> (message from Qiantan Hong on Tue, 29 Sep 2020 23:40:53 +0000) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:256753 Archived-At: > From: Qiantan Hong > Date: Tue, 29 Sep 2020 23:40:53 +0000 > Cc: Fermin , Jean Louis , > Noam Postavsky , Emacs developers , > Karl Fogel , Stefan Monnier > > > 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. > > 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?