From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Po Lu Newsgroups: gmane.emacs.devel Subject: Re: Android input methods Date: Mon, 13 Feb 2023 22:37:19 +0800 Message-ID: <87edqtws0w.fsf@yahoo.com> References: <83r0uvghw7.fsf@gnu.org> <87k00nyo60.fsf@yahoo.com> <83ilg7gdjj.fsf@gnu.org> <87bklyzyyj.fsf_-_@yahoo.com> <83a61iho6r.fsf@gnu.org> <87ttzqxq3f.fsf@yahoo.com> <83cz6dfzet.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26971"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Feb 13 15:40:34 2023 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 1pRa0O-0006pY-Kg for ged-emacs-devel@m.gmane-mx.org; Mon, 13 Feb 2023 15:40:32 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pRZzh-0005E2-U1; Mon, 13 Feb 2023 09:39:49 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pRZzg-0005DT-5f for emacs-devel@gnu.org; Mon, 13 Feb 2023 09:39:48 -0500 Original-Received: from sonic310-51.consmr.mail.ne1.yahoo.com ([66.163.186.232]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pRZzd-0004ze-Mp for emacs-devel@gnu.org; Mon, 13 Feb 2023 09:39:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1676299182; bh=WbCEUHR/N2aYxv8dFBMwMKdWY7OGLSxaIlPeJPV3370=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=lVerxxDFGliFjXDod+Tc35ja5dn9SIYs80H6tX72knk0CSW6btzzlweVrZdD9byGs24PpEzwk34cmY/drhHbKO3jL8+9Tdoqjp8FlWwIdzZjiQrSOk1VoSa3BjQDRshmABhtbbtPVlxQvroD9KVAfor8H3HCchWtCyCCkVcP5AwP3eZsaKY5AAVMF3CFw8YUhaP4pUFCE3V9QWcDV2zBy93YxHClo+m3s9ig7zzEee/K2KiufQjdY0SUeJfGSFA8d+c0+NcRUrTePwKr75mBROO2aJ2htNwAH2QBVacet33F5anfzFZNEHczE5fUKXPkOfYS6tyoUsmhfHTxdM+xIg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1676299182; bh=1CvXzBj6j6mI7KcS/IWhzJ1hJQok+bWgA6HAeELJ5TY=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=EDeNrS6qSaiGlOFuIOlbe6f6148X976msVHOxMQq0nehdkzkp1Zqa+P9+Zsvm9G51BBjLFNWpxdxhxadT20sMlxhTNbE6aTjb+2AhsyyJsJ/SNdzm7Yo6BeYWAJp6NJADWoMA1dUsz6LiGVl3U8PLzXN3FlKNCyFEgzuqp45xB3zmVv6lTJU7SazRAVeez4Yqqiz1p5JzWgaw/iQ3ORc66vuSc50mIsg9aKgam2W2R/YMiYDRCkSWHqpNoKPd6pN5WsMd8iNVlc3AHFdSEGYr4diRhdQDq+SmCVGlJNf8Fu1h/5ocX1pKBBokAtfqbbc9m7F2jGraCfZl+mu2cJq8w== X-YMail-OSG: ne_BP6IVM1mK014utOFN9.A7EpzXRpeTHZqfotAvblXdYgs8u6B5JIq9QEUEFoU DfMG9HSpsfQoAZOk8Alx_TvvodxxG.Ft9hbiXLS4cU478Yg10d9YoT54yHiuNhjUb9WgV4Au6B0D Gn_SAho67NLjTcJMh5xclvSuzFnrLxE9J3Yo3n0jIkPHKlPZMmNFy.So5QLrr_3czOSeAye6mYLa mlNTI9j1vcJM2m4J4JJN1PAyYhU_27faw2oKxrTFhnXYxSlXEP6vJxa7ahTJVch3.M7LdUUINgTb k8RgjYNzZ_.s3CXDiRgF85JDTbOTd7IW96iT9sILMcreQenvIZ5q7GFan1udn_44DzC1_fQpaLsO .ylZpT.3WGBYyP6p7NJbizAynJv7r_aS55KRObSxWzJJZgw07TJ_gUHm5M262FPIZ3TSVCsJTfLd p8JP_rA4E2epdJ09jx9.4zDj8GItggh8J00Cm9Gu3852Phoc1KxwR33MPCT5WZjCMAWqKgTGppvg a7JzFEzcqfXKJAM3BJtupoLcoZfJlxV.6Lpdmib8AhCwIMvwFLZyTcr2_RCOBy_LsV2AN0zdrDv2 C6c0u7xpSD.SxIwzize2JOBYsMm34WEPmNrLvrQOGevhDV2KlltKsa.Eo9KJjD1eVyluWBLG9W9U ZjBv3tie3pioHylQ1gUhc74b16.HpzjTHyfB0Wo0pi5v_6e2DoZHJvirF51LCtEQnuE2kc4Sp6NF etM354nCSyFJANBtVsqd2kV1pbYXxHZeyPJSt4LyKs6VGSrtCVp71SNrC_n.A_mWr8C7EMvyVVA5 zFZnPOfo0IsiMe6_LywGZk77Bmm3P7U3Gy3J.Zqva0 X-Sonic-MF: Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.ne1.yahoo.com with HTTP; Mon, 13 Feb 2023 14:39:42 +0000 Original-Received: by hermes--production-sg3-9fc5746c8-qs9hb (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 10d27be62629f77048d41099e04f9d6b; Mon, 13 Feb 2023 14:37:39 +0000 (UTC) In-Reply-To: <83cz6dfzet.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 13 Feb 2023 15:49:46 +0200") X-Mailer: WebService/1.1.21183 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Received-SPF: pass client-ip=66.163.186.232; envelope-from=luangruo@yahoo.com; helo=sonic310-51.consmr.mail.ne1.yahoo.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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.29 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:303215 Archived-At: Eli Zaretskii writes: >> My problem is that modes such as `electric-indent-mode' expect, for >> example, newline characters to be inserted by the return key, and do not >> indent if the change is made directly by the input method. > > is the only problem with such modes? Or are there other issues? There are many others: consider the vc-dir buffer: when you type ``mmmm i'', it expects individual key presses, each one of which marks a file or registers it with the VC system. > OK, so let's talk about the details in those case where we would like > to produce single-key events to Emacs. > > How large are the "preconversion text" regions in practice? You > described quite large regions, but I'm not sure I understand why an > input method would want to manipulate such a large portion of text. > Surely, inserting a single non-ASCII character never needs to > manipulate more than a few character positions? I mean, to type a > character one usually needs to enter a small number of keystrokes; > anything else would make typing extremely inconvenient and slow. > > If input methods are actually modifying relatively small portions of > text (even if they request much larger regions to do that), producing > single-key events from that should not be too hard: all you need is > compare two almost identical stretches of text. Am I missing > something? If you insert text, the input method might choose to suggest replacements for the text, typically of the surrounding word, but also sometimes up to entire sentences in length. In addition, there is a mode where the input method displays extracted text in a window of its own, and only sends the resulting changes back to Emacs after it finishes. Such changes can be almost arbitrary in many cases. However, I think I've found an easier solution that doesn't involve any text comparison: we can enable input methods only for editing modes that derive from `text-mode', and perhaps prog-mode as well, whilst utilizing the ASCII keyboard fallback on modes which derive from special-mode. It should be easy to fix electric indentation and other prog-mode-features to handle text insertion by the input method. Apparently (and this is not written in any documentation), if you set the input type to TYPE_CLASS_TEXT without providing any ``input method connection'', even input methods that normally don't provide the ASCII keyboard fallback can be convinced to do so. >> >> If Emacs makes a change to the buffer outside the area in which the >> >> input method expresses interest, then it is obligated to ``restart'' the >> >> input method. This takes a significant amount of time to complete. >> > >> > What does Emacs have to do to "restart" an input method? what does >> > this mean in practice? >> >> In practice, this means the input method will hide and reshow its >> editing window. > > The editing window is shown by the input method, not by Emacs, right? > I asked about what Emacs needs to do for this "restarting" action. > >> > And how much time is "a significant amount of time" in this case? >> >> Up to a second. > > So the user types something and the response is after 1 sec? Yes, if the editor makes an edit that the input method wasn't expecting, you will see the input method window disappear and reappear again up to a second later. It works in practice because editors do not do that. The period is apparently shorter if you turn off animations, but only the user can do that in the system settings. > No problems here, except the usual issue with our superset of UTF-8. > We'd need to encode the text. However, for relatively short stretches > of text this should be fast enough. And the other direction already > exists: decode_coding_gap. This should be easy: we provide character positions and Unicode characters to the input method, but use the NULL byte for characters that are not representable in UTF-16 (including those which need to be represented by surrogate pairs.) >> So, Emacs will have to implement (at least optional) translation >> between these complex editing commands and simple character input >> events. > > Yes, but AFAIU only to placate the electric-input features and > similar. Please see what I said above about toggling the input method behavior depending on the major mode of the selected buffer. >> > You mean, if I select, say, a Cyrillic keyboard and start typing, what >> > Emacs will see is the above complex insert/delete/replace commands >> > instead of a series of single Cyrillic characters? And this only >> > happens with non-ASCII characters, but not with ASCII? >> >> Yes, that's what will happen right now. > > Strange design. Any idea why non-ASCII characters get such complex > treatment? I don't know. It seems to be an initial oversight that had to be kept for backwards compatibility reasons, because applications do not expect key events with (a definite misnomer) the `unicode_char' field set to some value greater than 127. I can't find this written down anywhere, however, except there are simply no keymaps that map keys to larger characters.