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: Behavior of input method -- crdt.el Date: Sun, 18 Oct 2020 03:47:44 +0000 Message-ID: Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Apple-Mail=_D9978003-A058-4C31-B80A-32A9451FD16B"; protocol="application/pkcs7-signature"; micalg=sha-256 Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26096"; mail-complaints-to="usenet@ciao.gmane.io" To: EMACS development team Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Oct 18 05:48:48 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 1kTzgc-0006dZ-Dm for ged-emacs-devel@m.gmane-mx.org; Sun, 18 Oct 2020 05:48:46 +0200 Original-Received: from localhost ([::1]:40316 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kTzgb-0001lU-GB for ged-emacs-devel@m.gmane-mx.org; Sat, 17 Oct 2020 23:48:45 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51560) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kTzfh-0001Jc-85 for emacs-devel@gnu.org; Sat, 17 Oct 2020 23:47:49 -0400 Original-Received: from outgoing-exchange-7.mit.edu ([18.9.28.58]:58215) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kTzff-0007mS-4V for emacs-devel@gnu.org; Sat, 17 Oct 2020 23:47:48 -0400 Original-Received: from oc11exedge1.exchange.mit.edu (OC11EXEDGE1.EXCHANGE.MIT.EDU [18.9.3.17]) by outgoing-exchange-7.mit.edu (8.14.7/8.12.4) with ESMTP id 09I3liVD011683 for ; Sat, 17 Oct 2020 23:47:45 -0400 Original-Received: from oc11expo16.exchange.mit.edu (18.9.4.47) by oc11exedge1.exchange.mit.edu (18.9.3.17) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Sat, 17 Oct 2020 23:47:39 -0400 Original-Received: from oc11expo16.exchange.mit.edu (18.9.4.47) by oc11expo16.exchange.mit.edu (18.9.4.47) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Sat, 17 Oct 2020 23:47:44 -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; Sat, 17 Oct 2020 23:47:44 -0400 Thread-Topic: Behavior of input method -- crdt.el Thread-Index: AQHWpQFvQnthIc4iN0qpZZJ/fOw2ig== 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.58; envelope-from=qhong@mit.edu; helo=outgoing-exchange-7.mit.edu X-detected-operating-system: by eggs.gnu.org: First seen = 2020/10/17 23:47:45 X-ACL-Warn: Detected OS = Windows 7 (Websense crawler) X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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:257984 Archived-At: --Apple-Mail=_D9978003-A058-4C31-B80A-32A9451FD16B Content-Type: multipart/alternative; boundary="Apple-Mail=_61777436-5414-498B-B279-C74992D58C32" --Apple-Mail=_61777436-5414-498B-B279-C74992D58C32 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, I=E2=80=99m now working on the compatibility between=20 https://code.librehq.com/qhong/crdt.el = and Emacs input methods. There might be the case that one peer is in the halfway of input some characters using input method (it seems that at this state, there are some temporary text inserted in the buffer without calling *-change-functions), and some changes from other peer arrives. After resolving the position of the changes, crdt.el move point to the resolved position and use INSERT to insert the characters from remote peer. In the case that these other changes happen to at exactly the same position that current user is inserting using input method, seems that the input method get confused and consider those inserted character as part of its halfway input. It doesn=E2=80=99t affect character = selection, but when user finally select a character, it erase both the halfway input and the inserted remote characters. Now the peers are inconsistent. Anyone have any idea on how to workaround this? To be more clear, a concrete example: User1 is typing using chinese-py. User1=E2=80=99s buffer: ce User2=E2=80=99s buffer:=20 User2 type a =E2=80=9Ct=E2=80=9D at the begining User1=E2=80=99s buffer: tce User2=E2=80=99s buffer: t User1 finish selection User1=E2=80=99s buffer: =E6=B5=8B User2=E2=80=99s buffer: t=E6=B5=8B Notice that the input method also erase t. Now both user=E2=80=99s buffers are inconsistent. Best, Qiantan --Apple-Mail=_61777436-5414-498B-B279-C74992D58C32 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

I=E2=80= =99m now working on the compatibility between 
https://code.librehq.com/qhong/crdt.el and Emacs = input methods.
There might be the case that one = peer is in the halfway of input
some characters = using input method (it seems that at this state,
there are some temporary text inserted in the buffer without = calling
*-change-functions), and some changes from = other peer arrives.

After resolving the position of the changes, crdt.el move = point
to the resolved position and use INSERT to = insert the characters
from remote peer.
In the case that these other changes happen to at exactly the = same
position that current user is inserting using = input method, seems that
the input method get = confused and consider those inserted character
as = part of its halfway input. It doesn=E2=80=99t affect character = selection, but
when user finally select a = character, it erase both the halfway input
and the = inserted remote characters. Now the peers are inconsistent.

Anyone have any idea on = how to workaround this?

To be more clear, a concrete example:

User1 is typing using = chinese-py.
User1=E2=80=99s buffer: ce
User2=E2=80=99s buffer: 

User2 type a =E2=80=9Ct=E2=80=9D at the = begining
User1=E2=80=99s buffer: tce
User2=E2=80=99s buffer: t

User1 finish selection
User1=E2=80=99s buffer: =E6=B5=8B
User2=E2=80=99s buffer: t=E6=B5=8B
Notice = that the input method also erase t.

Now both user=E2=80=99s buffers are = inconsistent.


Best,
Qiantan

= --Apple-Mail=_61777436-5414-498B-B279-C74992D58C32-- --Apple-Mail=_D9978003-A058-4C31-B80A-32A9451FD16B 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 AQcBMBwGCSqGSIb3DQEJBTEPFw0yMDEwMTgwMzQ3NDRaMC8GCSqGSIb3DQEJBDEiBCBrWOSKPubm 76aoD77TZ+T1s8ETksr0YWtIFSLTZxFzKjCBkQYJKwYBBAGCNxAEMYGDMIGAMGwxCzAJBgNVBAYT AlVTMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMS4wLAYDVQQKEyVNYXNzYWNodXNldHRzIEluc3Rp dHV0ZSBvZiBUZWNobm9sb2d5MRUwEwYDVQQLEwxDbGllbnQgQ0EgdjECEBqqXf02w7WotWORLaGX nXswgZMGCyqGSIb3DQEJEAILMYGDoIGAMGwxCzAJBgNVBAYTAlVTMRYwFAYDVQQIEw1NYXNzYWNo dXNldHRzMS4wLAYDVQQKEyVNYXNzYWNodXNldHRzIEluc3RpdHV0ZSBvZiBUZWNobm9sb2d5MRUw EwYDVQQLEwxDbGllbnQgQ0EgdjECEBqqXf02w7WotWORLaGXnXswDQYJKoZIhvcNAQEBBQAEggEA WfavocukvfUjUXWJeDCQ1mfT1hsWnn+okqv5VyWF/EqJU0aTqFlvO88JbZ49CWg6z1/SnCTkUz7t GBiy/BZ5A7GTDtncfx9UB6PZW+0QcjYW+NFCmseyQ7rcmxWaZKS9KxLz8iSHE7eX0qqzBAEs7dFt qi2h70wvuyK8ORmRNOwVm1d/YisThKu3hAuWNjsYWyhlb6ldS1c6444CMPmCMnWkpwgW+hRgWSSP 2/Gi4wEEJ+V3D2NE66aBqDfOcYuXSGZbo3cAHmFPTkp1gFG6xPFVQU5ryd0IRHHmr8e8ry/m5s8L 9WoRrMrdGRzyeRsnPNDh0d9TcF/9s0HbXLn81gAAAAAAAA== --Apple-Mail=_D9978003-A058-4C31-B80A-32A9451FD16B--