From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Qiantan Hong Newsgroups: gmane.emacs.devel Subject: Re: Question collaborative editing. Date: Wed, 30 Sep 2020 15:47:04 +0000 Message-ID: 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: multipart/signed; boundary="Apple-Mail=_77F5205D-06AE-4A2E-86A9-CDD3E2CE6BFA"; protocol="application/pkcs7-signature"; micalg=sha-256 Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14414"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Ergus , Fermin , Jean Louis , Noam Postavsky , Emacs developers , Karl Fogel , Stefan Monnier To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Sep 30 17:49:27 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 1kNeMB-0003bn-IB for ged-emacs-devel@m.gmane-mx.org; Wed, 30 Sep 2020 17:49:27 +0200 Original-Received: from localhost ([::1]:56536 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kNeMA-0000l7-HV for ged-emacs-devel@m.gmane-mx.org; Wed, 30 Sep 2020 11:49:26 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46548) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kNeKC-0008Vq-30 for emacs-devel@gnu.org; Wed, 30 Sep 2020 11:47:24 -0400 Original-Received: from outgoing-exchange-1.mit.edu ([18.9.28.15]:45838) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kNeK9-0000jM-TK for emacs-devel@gnu.org; Wed, 30 Sep 2020 11:47:23 -0400 Original-Received: from oc11exedge1.exchange.mit.edu (OC11EXEDGE1.EXCHANGE.MIT.EDU [18.9.3.17]) by outgoing-exchange-1.mit.edu (8.14.7/8.12.4) with ESMTP id 08UFkurr006766; Wed, 30 Sep 2020 11:47:16 -0400 Original-Received: from w92expo16.exchange.mit.edu (18.7.74.70) by oc11exedge1.exchange.mit.edu (18.9.3.17) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Wed, 30 Sep 2020 11:46:25 -0400 Original-Received: from oc11expo16.exchange.mit.edu (18.9.4.47) by w92expo16.exchange.mit.edu (18.7.74.70) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 30 Sep 2020 11:47:04 -0400 Original-Received: from oc11expo16.exchange.mit.edu ([18.9.4.47]) by oc11expo16.exchange.mit.edu ([18.9.4.47]) with mapi id 15.00.1365.000; Wed, 30 Sep 2020 11:47:04 -0400 Thread-Topic: Question collaborative editing. Thread-Index: AQHWkA+RtV3K1wr9B0aFczVHqkD+n6lzGC2+gAByx1WAA75ZgIABUIuAgAAtCoCAAKrvgIAEEd+AgAGGOACAABFAAIAAe9OAgABIs4CAAA5xVYAAjDuAgAAchYCAAKh2a4AAZX0A In-Reply-To: <83a6x7js6y.fsf@gnu.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [18.18.245.17] Received-SPF: pass client-ip=18.9.28.15; envelope-from=qhong@mit.edu; helo=outgoing-exchange-1.mit.edu X-detected-operating-system: by eggs.gnu.org: First seen = 2020/09/30 11:47:19 X-ACL-Warn: Detected OS = Windows 7 (Websense crawler) X-Spam_score_int: -22 X-Spam_score: -2.3 X-Spam_bar: -- X-Spam_report: (-2.3 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.373, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:256764 Archived-At: --Apple-Mail=_77F5205D-06AE-4A2E-86A9-CDD3E2CE6BFA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 >> I=E2=80=99m not sure if it=E2=80=99s easy (or worth the effort) to = provide CRDT in an=20 >> 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=E2=80=99m = implementing >> it in this way as an Elisp library. However, this relies on the = particular >> data structure for buffer/text emacs uses. >>=20 >> 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=E2=80=99 .. doesn=E2=80=99t sound so clean. >=20 > 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=20= to get in sync is a likely source of bug and maintenance problems.=20 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 =E2=80=94 because they are item based rather than buffer position based. Suppose it=E2=80=99s implemented in C library way and C library communicate to Emacs via buffer position information =E2=80=94 the extra text will make the position off and completely mess up any further operation on this buffer. Also this scenario doesn=E2=80=99t necessarily comes from a bug in CRDT implementation =E2=80=94 there=E2=80=99s inhibit-modification-hooks = which may prevent some changes to be told to the C library. I agree that there=E2=80=99s no problem with C library if everything = behaves well =E2=80=94 I don=E2=80=99t 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.= --Apple-Mail=_77F5205D-06AE-4A2E-86A9-CDD3E2CE6BFA Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCA70w ggO5MIIDIqADAgECAhAaql39NsO1qLVjkS2hl517MA0GCSqGSIb3DQEBCwUAMGwxCzAJBgNVBAYT AlVTMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMS4wLAYDVQQKEyVNYXNzYWNodXNldHRzIEluc3Rp dHV0ZSBvZiBUZWNobm9sb2d5MRUwEwYDVQQLEwxDbGllbnQgQ0EgdjEwHhcNMjAwODAzMDEyNDIz WhcNMjEwODAxMDEyNDIzWjCBoTELMAkGA1UEBhMCVVMxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMx LjAsBgNVBAoTJU1hc3NhY2h1c2V0dHMgSW5zdGl0dXRlIG9mIFRlY2hub2xvZ3kxFTATBgNVBAsT DENsaWVudCBDQSB2MTEVMBMGA1UEAxMMUWlhbnRhbiBIb25nMRwwGgYJKoZIhvcNAQkBFg1xaG9u Z0BNSVQuRURVMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAylUlEQdK4BSXKzoGh6As CKN/TpLmC0kjhPdxUKMj1/86Xl6GDCla4h95uISDOWVAKdu3cIlA8m9zRLT2jNEIkt1DVpXP6c9h y8RRyfJm0qlrvr6tsHi5AmO4Li6s2dEGaTxbakPL6vEn7ZYr86t5orq56nubki77Z8ZvRv9/fWdF bF/YBNGDayLNk0NbXIEQdCHiz1l+bxfw+GHHRmdOge3MKWSg463+GGMdxtLQ61AbtR2vm47FIJBt c0X6ptcInWUg4Nf/9vSNGl6KvREvfbEWKCT6TfL5ncIFlitf6ZWKue2PZ4ULFfIQ3/7EsEk03xxr S7sTOy7e2dbPboe/WwIDAQABo4GhMIGeMAkGA1UdEwQCMAAwEQYJYIZIAYb4QgEBBAQDAgWgMB0G A1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjALBgNVHQ8EBAMCBeAwHQYDVR0OBBYEFDeb9Jlj XSm+y0CD872IhzRDIGv1MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jYS5taXQuZWR1L2NhL21p dGNsaWVudC5jcmwwDQYJKoZIhvcNAQELBQADgYEApBTx4tBbD5rQ+bNGd/Z3OBV07qFsm5QHNg0+ 6lxJ3j7q5zMMq35o6y5cBIhcFG6t+MFqJIdERZ3EprDturyqozQsIBMHFnqh+iZcMg0uQyssEqKZ hrzIdw8GuY4Z6jNewdGy5mwwG9yjpEbzWWgdofSM5rnezZz7EvCQu9ilt1sxggNDMIIDPwIBATCB gDBsMQswCQYDVQQGEwJVUzEWMBQGA1UECBMNTWFzc2FjaHVzZXR0czEuMCwGA1UEChMlTWFzc2Fj aHVzZXR0cyBJbnN0aXR1dGUgb2YgVGVjaG5vbG9neTEVMBMGA1UECxMMQ2xpZW50IENBIHYxAhAa ql39NsO1qLVjkS2hl517MA0GCWCGSAFlAwQCAQUAoIIBkzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA5MzAxNTQ3MDRaMC8GCSqGSIb3DQEJBDEiBCDEcPNY4TTR Yw6lLOl6bldJ7wIYSUUd8ku6cTXOhRCanjCBkQYJKwYBBAGCNxAEMYGDMIGAMGwxCzAJBgNVBAYT AlVTMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMS4wLAYDVQQKEyVNYXNzYWNodXNldHRzIEluc3Rp dHV0ZSBvZiBUZWNobm9sb2d5MRUwEwYDVQQLEwxDbGllbnQgQ0EgdjECEBqqXf02w7WotWORLaGX nXswgZMGCyqGSIb3DQEJEAILMYGDoIGAMGwxCzAJBgNVBAYTAlVTMRYwFAYDVQQIEw1NYXNzYWNo dXNldHRzMS4wLAYDVQQKEyVNYXNzYWNodXNldHRzIEluc3RpdHV0ZSBvZiBUZWNobm9sb2d5MRUw EwYDVQQLEwxDbGllbnQgQ0EgdjECEBqqXf02w7WotWORLaGXnXswDQYJKoZIhvcNAQEBBQAEggEA lNAFbWUsA+yqPFkA6xBn/ojaHOurTftRn5LZBSpM6pKEXDdAS/qIF++JrIyjreGcko2MxORi7npL aBzAEiVgKO4P/sqLu/8JuRM+YBlBewDqvXQ0Zf2MoeZkAAsgcZvlRFvssiif73TUatD+l3uLUJSH 7Q70hjwvlotidYFKEw3YaBl5WuO5xg5TKcWgpozTHGW2VVZarNVB0tgDkxhH2SESzMFldSd6VHd9 Rytv4nupudGPSKiOfc344CSdpRU5ZCLQq0cpj6rbWi0e4cDXyXFIv8kBsNfCiqA2lerD8A+MKs51 TSyXUsI4xsS7/jgzaWAK8f/3rXEZ0LO8xmN9cgAAAAAAAA== --Apple-Mail=_77F5205D-06AE-4A2E-86A9-CDD3E2CE6BFA--