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 Date: Mon, 13 Feb 2023 15:49:46 +0200 Message-ID: <83cz6dfzet.fsf@gnu.org> 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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13285"; 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 Mon Feb 13 14:51:04 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 1pRZEU-0003C1-8E for ged-emacs-devel@m.gmane-mx.org; Mon, 13 Feb 2023 14:51:02 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pRZDk-0000eS-Ce; Mon, 13 Feb 2023 08:50:16 -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 1pRZDi-0000dz-W9 for emacs-devel@gnu.org; Mon, 13 Feb 2023 08:50:15 -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 1pRZDi-0003eN-Mp; Mon, 13 Feb 2023 08:50:14 -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=L4zP1dzWyWlb3YVfowxYvp+nLVPhrTPY6Pk/pp0Iv5Y=; b=OkrVJ5SEXqW9 9FR3N7Tl3dBPFiymsrk4mk1tI/Wrb9Od9k1Xn/7xUVdCiNWYcVx2yC15iyPf+n/zumEp9EKdYpIvv XGpOPD8FLJCyMqewfrD1VR6oGH+b9cVSwK0rqaPUqEFOC7oBxaN/gl1EUPz9KJmJQFotFocwbWxMN q9ekWtf+CX5aZ3T0LsgnWqG8Y2xB8pYqujSU9BRRJRWGrJQ4SztBREEov7Tc1NQjYyzO9AnuRbKNX 17M+jQbt7L/yssvY861x+08reY+xr/cOTlk6FzTIuoYtJdJDfB8p1BUzEUWOa8cCcS5SCc/1WeA5G dXhGnfSKx0BYfqKW9Wdukw==; 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 1pRZDi-0007Fj-63; Mon, 13 Feb 2023 08:50:14 -0500 In-Reply-To: <87ttzqxq3f.fsf@yahoo.com> (message from Po Lu on Mon, 13 Feb 2023 10:21:24 +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:303213 Archived-At: > From: Po Lu > Cc: emacs-devel@gnu.org > Date: Mon, 13 Feb 2023 10:21:24 +0800 > > 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. is the only problem with such modes? Or are there other issues? > 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. 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 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? > > 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. 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. > > 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. No problem here, then. > >> 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. That's no accurate: a process filter can (and many do) insert text directly into the buffer, in relatively large chunks. > 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. > > 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?