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 19:19:43 +0300 Message-ID: <83eemji6e8.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> <83a6x7js6y.fsf@gnu.org> 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="39039"; 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 18:20:36 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 1kNeqJ-000A2g-PF for ged-emacs-devel@m.gmane-mx.org; Wed, 30 Sep 2020 18:20:35 +0200 Original-Received: from localhost ([::1]:56582 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kNeqI-0008Vc-RT for ged-emacs-devel@m.gmane-mx.org; Wed, 30 Sep 2020 12:20:34 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59328) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kNepd-00084w-SC for emacs-devel@gnu.org; Wed, 30 Sep 2020 12:19:53 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:37417) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kNepb-0004Ul-VI; Wed, 30 Sep 2020 12:19:51 -0400 Original-Received: from [176.228.60.248] (port=2897 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kNepa-0001gK-Ss; Wed, 30 Sep 2020 12:19:51 -0400 In-Reply-To: (message from Qiantan Hong on Wed, 30 Sep 2020 15:47:04 +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:256767 Archived-At: > From: Qiantan Hong > Date: Wed, 30 Sep 2020 15:47:04 +0000 > Cc: Ergus , Fermin , > Jean Louis , Noam Postavsky , > Emacs developers , Karl Fogel , > Stefan Monnier > > > [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.