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: Android input methods (was: Re: textconv.c) Date: Sun, 12 Feb 2023 17:57:00 +0200 Message-ID: <83a61iho6r.fsf@gnu.org> References: <83r0uvghw7.fsf@gnu.org> <87k00nyo60.fsf@yahoo.com> <83ilg7gdjj.fsf@gnu.org> <87bklyzyyj.fsf_-_@yahoo.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1781"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Feb 12 16:58:20 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 1pREk8-0000IP-HQ for ged-emacs-devel@m.gmane-mx.org; Sun, 12 Feb 2023 16:58:20 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pREjL-0007P0-84; Sun, 12 Feb 2023 10:57:31 -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 1pREjH-0007NI-Pi for emacs-devel@gnu.org; Sun, 12 Feb 2023 10:57:27 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pREjH-0006rT-FR; Sun, 12 Feb 2023 10:57:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=XuB8KhmiFsvEviWzqemHFaKOLe5r4gXrWzxCV21IYjs=; b=O//e7A1dwBxn +/fhinJgU0ybvpvrzWxPQc0snDsDKCr9mB6UOg8cFki/bD91qR+NgCfA8ttG4rrD+jOcg5XPy8BRT KJaRuAbytd6SD3SdioSV+nu/6SjYh/QNHA0nSqntBkK5eh/uFw5bJm44XTTD1I//QOUAmybCin4ew MZaZ7nrBAffapINTmwgHa1SNlhpe7Tk7mFcirypf7q7DYrhF5F735iSftTwU6xhZ7XTtXcS9NUs1d JJ5rpGUJJHmATn/j/O4iCtNeW8PmPuxx7BcWoGHpbymm0CAqhn8CzsHNclrzZ847BX90ypPMUuJhT +DzfYhoZLoWtw5XT+NRYPg==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pREjG-0001Sp-PK; Sun, 12 Feb 2023 10:57:27 -0500 In-Reply-To: <87bklyzyyj.fsf_-_@yahoo.com> (message from Po Lu on Sun, 12 Feb 2023 23:27:00 +0800) 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:303183 Archived-At: > From: Po Lu > Cc: emacs-devel@gnu.org > Date: Sun, 12 Feb 2023 23:27:00 +0800 > > Eli Zaretskii writes: > > > I don't see why this is important, since you can switch the buffer > > temporarily. We do this all over the place, since insdel.c always > > works on the current buffer. > > The text is copied into a C ``char *'', not into another buffer. A buffer in Emacs is just a linear array of bytes, so the above supports copying into a buffer and from a buffer as well. Once again, look at the callers of copy_text, and you will see it. > On Android, input methods work the other way around. They do the text > insertion and deletion themselves, all whilst querying the text editor > about the position of the caret (point) and the text around it for > reference. Emacs is only told to insert or delete text at a specific > position in its buffer, and is obligated to inform the input method > about changes around the caret. 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. > 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? And how much time is "a significant amount of time" in this case? > 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? > 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? > But the input method will stop working properly until the next time > it is reset if it doesn't see the replacement reflected in Emacs's > own buffer contents. How can the input method know that the replacement is reflected in the Emacs buffer? > 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...? > Now, it is sometimes possible to disable the input method and to simply > work with an on screen keyboard (which is what the Android port > currently does), but that precludes entering any non-ASCII text, and is > a luxury which is only affored by several input methods. 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?