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: master 02bca34: Utilize new string decoding feature in GTK native input Date: Sat, 19 Feb 2022 11:35:11 +0200 Message-ID: <83czjjyzao.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33221"; 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 Sat Feb 19 10:37:10 2022 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 1nLMAw-0008VS-4G for ged-emacs-devel@m.gmane-mx.org; Sat, 19 Feb 2022 10:37:10 +0100 Original-Received: from localhost ([::1]:42558 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nLMAu-00052e-GZ for ged-emacs-devel@m.gmane-mx.org; Sat, 19 Feb 2022 04:37:08 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:41522) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nLM9B-0004Dm-Pj for emacs-devel@gnu.org; Sat, 19 Feb 2022 04:35:21 -0500 Original-Received: from [2001:470:142:3::e] (port=55518 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nLM9B-00050L-8a; Sat, 19 Feb 2022 04:35:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=Subject:To:From:Date:mime-version:in-reply-to: references; bh=DeRe/c+jG7uXACAm7A1nyGZ93Ni4U0AuBWtLfE3QsG0=; b=GU5/PPGybwp09M 8KYWb3KL2SM9Xeb10FEjNSggyoBBZFWeFj4m+YBt5A6EpK+qiSQk7M8G+UnJGD5OyGOGYuX5trdwB 8qaKZ4e6xl4zT6nHvH3z1xMYnAbkJk+KCekzuB0rNLKcUug4T7ZnozOKqWsjXSjGwaelmmhAiAMcf xHeC/DhqleQ1ah2mW0S9w453JRqRh8fy1AeBa3TrwE5KfnB2AKCBYChoa2GpX8IfSvV6XkzofoN1W VAjcGI2uiG75ZwX/cNhmTu7RjpT5x1w3xBGkB1W9n3q9dNSMlyZluEV+9tvgAk1nIdiCbf+GqCvo9 B98sPdH9IquGMADqz7/Q==; Original-Received: from [87.69.77.57] (port=2534 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 1nLM93-0003GA-1Z; Sat, 19 Feb 2022 04:35:21 -0500 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" Xref: news.gmane.io gmane.emacs.devel:286458 Archived-At: > commit 02bca34852b1f9dd2b3e5364274452d377686f6a > Author: Po Lu > AuthorDate: Sat Feb 19 09:18:27 2022 +0800 > Commit: Po Lu > CommitDate: Sat Feb 19 09:18:27 2022 +0800 > > Utilize new string decoding feature in GTK native input > > * src/gtkutil.c (xg_im_context_commit): Don't decode strings > manually using g_utf8_to_ucs4 but pass unibyte string as the > keystroke event arg instead. Is this a good idea? Consing a string when we process input increases GC pressure, and what issues does this change solve as a counter-weight for that disadvantage? Is g_utf8_to_ucs4 a problematic API or something? If so, we could use our own implementation instead. But in general, decoding UTF-8 encoded C string is better done without consing a string and then using the coding.c stuff. After all, if the original string is 100% guaranteed to be in UTF-8, the decoding is almost trivial.