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 10:21:24 +0800 Message-ID: <87ttzqxq3f.fsf@yahoo.com> References: <83r0uvghw7.fsf@gnu.org> <87k00nyo60.fsf@yahoo.com> <83ilg7gdjj.fsf@gnu.org> <87bklyzyyj.fsf_-_@yahoo.com> <83a61iho6r.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="35942"; 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 03:24:36 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 1pROWC-0009C1-4a for ged-emacs-devel@m.gmane-mx.org; Mon, 13 Feb 2023 03:24:36 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pROVS-0000Jf-Qo; Sun, 12 Feb 2023 21:23:50 -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 1pROVQ-0000JU-GB for emacs-devel@gnu.org; Sun, 12 Feb 2023 21:23:48 -0500 Original-Received: from sonic316-48.consmr.mail.ne1.yahoo.com ([66.163.187.174]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pROVO-0002G7-Cu for emacs-devel@gnu.org; Sun, 12 Feb 2023 21:23:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1676255023; bh=xXpFDjEuCS9F1YfXalWHhs5n4wK1vdWDAqeT5/shn58=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=gR+48L0afN+Rrpk10oaenn+WiwOl+diQqJ9WWFnPBvC7ErF3I5ro6W2mUS1rW7H+Uvx+st4RhT0rBxggjZMyBB6SnJEqvc/Xjg0kv+2Mi1cS2nLDyViNYukyquE7w32XxtqBBYNfu0qf5hPb24txugg2fYRNTZ2sPAjlqD3hEAhQkPL63X1+rnx+fVBVIzd6O4oIxQBSYir5H7aMgQYu3Asrs5WDu7BZpwQ9XSlON52XBGaWZPUit+MsRHcMv+FuEfSjURd5Jb8FXqFK+KTNUdFtDz42iC6H4rm9efwWzvC1+EXTIz4QXp3Rl8QQk0pNpjZ0RvBQNwiiW+0Xab/ntQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1676255023; bh=QEy9ObRBS8/MMdQBNKOAvcy/a5GQF2lcm9aG+IQNrxK=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=Jq7m/rNODYEfFsSkgibPP/ufqgz+YEve/dmEGC/Z9v9++f+pL43xtVlLSGPyycr24r25YZHa+kHu3nJ2nMqC2ylOgkB7rgIQxfoEmJrwlTG8+dPX/zmYzgFbePGJfmPFOG/a5DqN/Lgn2A8wVolbEBAVEXAtbYAq9SkmOrfzWv1f5tkH7WiUNcZWKZ82Qk7IjxV19uOz4VZ2w6mUI8GPC41dKrjRFKCdyPdL9Bj0LfgyOa3uW2uk81YOhFO8qXD1l38TH/UTj38uEuTXW0r3rpX8JSR8Ph5xvWa/Li0miVeIYta99glkjwVLgMMERDatt1nSg+mhAi6Sk9s9pTZX1w== X-YMail-OSG: YHxsNlkVM1nMwd.RLkf3.e3l89e6_Dhjdq7pibqlihfTgkscZnNmOlU18Y3QtSv 9NJnDOy7VTFwt2GVg9M8QJ2dHE5.tfQb16uvlekqpz3SJ6L2xtPEsj6IrL8RnOeVzbrsn0YINKxo M.PaDpKdHDiWHE6EGrnC4yQ1_tHRGxNuUlzBUL2Jw8jTDZDSA1Jvy1QwLPQnobDK21.j0KlS9JQV JS.IMITfdwfbTm93tFqxLOJGwBR7Hd32INN3fbwH82NenseS23TZSGcGQeK.5d71b3C8bIV4ZuvE jrWbSOtP17Vdf8liFlQu3IDY0aHWHma8xschvAd4.aoFU_gBGZhHfeJ_9BFn4SMel21Gc89XRVFs Up7PvjWCLR4CoR.s__h.cWKXF_rwc2VQpwoRpIA6ew7fvw1.8gUQFq2qIHMHzXvsmYG5dph3dmxI 85xNCC1nsL2ZCF0HXxTryDi.IqQiaxFPU5alE_9N1nkBsndIGSh3vm63dSt6bygAw_GAOtvfbtEv mkZUobMACYHGoq4VxWjtYFdejAqUVSAiE5xpEvJvMBJBTr81o3tXPPMXO2tVdsOMQFOL85zJ54tc 4XiMl9Vf0x5UfE_OoPicvkG6oALhiVqNcl3aXnLWHMtNY8ZgNUrGQbZoeJmYttXbOXyWiCpOcNp6 QAdAkdZqZmozzydljCoK8fSn6EMm_P6rlhby2NA1U2.M6AYgjdKv.LNr28Ln12dAA4MHRYY9Y4x7 9wLru9SR687xTQJ2m0h4CPuG8QNNQWiGLrUwhqypvFNTYQKBi634BmqovJhZgV64S7hblm_y_jii EazzbgT87OqB4bx5So2eSoGI.devSnt8zgDfYAo5GY X-Sonic-MF: Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.ne1.yahoo.com with HTTP; Mon, 13 Feb 2023 02:23:43 +0000 Original-Received: by hermes--production-sg3-9fc5746c8-ltdwf (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID eb80b49f813fc4e32bfcdd1e26af59f2; Mon, 13 Feb 2023 02:21:40 +0000 (UTC) In-Reply-To: <83a61iho6r.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 12 Feb 2023 17:57:00 +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.187.174; envelope-from=luangruo@yahoo.com; helo=sonic316-48.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:303207 Archived-At: Eli Zaretskii writes: > Maybe I'm missing something, but where's the problem in this? We have > all this implemented in insdel.c, and a command can tell Emacs to > insert, delete, or replace text. IOW, so far you describe the > communications between Emacs and the input method as a stream of > insert/delete/replace commands, for which we already have all the > infrastructure, and the only thing that's missing is the low-level > communication protocol with the input method, which should issue those > commands. 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. So at least until the other major modes are adjusted to work with these input methods, there will need to be complicated conversion between input method editing commands and the key events which will normally perform the same thing. >> 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. > And how much time is "a significant amount of time" in this case? Up to a second. >> Sometimes, the input method will also tell Emacs to mark a portion of >> the buffer as ``preconversion text'' (or a ``composing span''), which is >> an ephemeral region which may be replaced by the input method by some >> other text, or deleted altogether. > > Again, I see no problems with this: markers will handle such a region. > >> at that point, the input method asks for the contents of the buffer >> before point again, and repeats the whole process. > > What does "asks for the contents of the buffer" mean in practice? what > does the input method tell Emacs, and what does it expect from Emacs > in response? if it expects us to send it the text it requested, then > how (by which medium and protocol) is that text sent by Emacs to the > input method? When this happens, the input method specifies an offset around the caret or absolute buffer positions, and calls a callback. Emacs is then supposed to reply by returning the text from that callback. >> All of this is behavior I have observed CJK and English input methods >> perform. An input method is not obligated to behave in any way like >> what I have described above, as long as it constrains its edits to some >> reasonable position (600 characters) around the caret; if it makes edits >> any further away from the caret than that, the behavior of the >> application is undefined. > > "Undefined" meaning that input methods will not usually do this? Or > what does it mean? It means that input methods are not allowed to do this, so applications don't have to allow it to happen. > How can the input method know that the replacement is reflected in the > Emacs buffer? It will either query for the buffer contents after some time, or monitor for the change. >> Sometimes, an input method will also monitor changes to the caret >> position. At this point, Emacs is obligated to report any changes to >> the on screen caret to the input method, so it knows where it should >> begin to make edits from. > > Again no problem for us: "we have the technology", in the form of > buffer-modification hooks. > >> An input method might also ask for a region of text to be ``extracted'', >> which means Emacs must report each change to the buffer that modifies >> said region to the input method > > Same. > >> In any case, the conclusion is that Emacs must present a completely >> correct view of the buffer contents of the selected window and the >> location of its point to the input method, correctly report edits made >> by the input method to the buffer contents and any edits made by Emacs >> after that, and dilligently report changes to extracted text and/or >> reset the input method on ``major changes'' such as the selected buffer >> or window changing, or edits happening outside extracted text. > > And the problem with doing what the input method expects is...? That most of Emacs expects character input events, and not for text to be changed underneath its nose. So, Emacs will have to implement (at least optional) translation between these complex editing commands and simple character input events. > 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.