From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: uzibalqa via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#58326: Reading unicode user inputs from minibuffer Date: Thu, 06 Oct 2022 11:51:06 +0000 Message-ID: References: <4JeAP4C-ZmLaQniOjh6tgvkryDVmyM6G9LF_Pb__wtnB5A8OG4aAkveITKDWok0Gf5BhSs014vvS2bdmqlUmfsLVqz1BWlvAOLXlEAFLLIM=@proton.me> <87mta9732z.fsf@gmail.com> Reply-To: uzibalqa Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37158"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 58326@debbugs.gnu.org To: Robert Pluim Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Oct 06 14:41:13 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1ogQBb-0009NR-0B for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 06 Oct 2022 14:41:11 +0200 Original-Received: from localhost ([::1]:59024 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ogQBZ-00043K-SQ for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 06 Oct 2022 08:41:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45842) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ogPQ2-0005Cr-Ud for bug-gnu-emacs@gnu.org; Thu, 06 Oct 2022 07:52:05 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:60080) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ogPQ2-0002tw-7t for bug-gnu-emacs@gnu.org; Thu, 06 Oct 2022 07:52:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ogPQ1-00040z-P8 for bug-gnu-emacs@gnu.org; Thu, 06 Oct 2022 07:52:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: uzibalqa Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 06 Oct 2022 11:52:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 58326 X-GNU-PR-Package: emacs Original-Received: via spool by 58326-submit@debbugs.gnu.org id=B58326.166505708415381 (code B ref 58326); Thu, 06 Oct 2022 11:52:01 +0000 Original-Received: (at 58326) by debbugs.gnu.org; 6 Oct 2022 11:51:24 +0000 Original-Received: from localhost ([127.0.0.1]:59158 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ogPPP-000401-KW for submit@debbugs.gnu.org; Thu, 06 Oct 2022 07:51:24 -0400 Original-Received: from mail-40141.protonmail.ch ([185.70.40.141]:19745) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ogPPK-0003zk-U7 for 58326@debbugs.gnu.org; Thu, 06 Oct 2022 07:51:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1665057072; x=1665316272; bh=HhqCUM7slnxWJKRBuzPoNuy2mvYy8ZQ1ev0wljP7xxo=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID; b=U/3954VZW/Op2/WW7PNH0vsVJlnU0bMFPk2BenWgvIDYW94BPEjQ039tgvYMwDtOy rgfQyojJsAZoaR/gjMY4uLG76NXUrbwYnGMzL/aqZAC4vqwOyzn4rJYkqoazAYRvNd 4qMSc41fzOz4rmAqnDXI3w+0P2kij65dsJC1VG1lxy1qMDHV4KRMtdGO8sn2NnZh06 VLCPJ5sWTSvpWiy0qjp/9PhVzMZ7WADx7oIjvBSqF2fnu4+6m0oUkN7fzrGjU4agzh Owp0wG3u2hnObLaYJ+eBNsyTnsjoWFLVhaFq7OFR6NKCQrD4hWB61GHkxQYSDnomjR 827wEgsXEB9tw== In-Reply-To: <87mta9732z.fsf@gmail.com> Feedback-ID: 52887082:user:proton X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:244650 Archived-At: ------- Original Message ------- On Thursday, October 6th, 2022 at 8:45 AM, Robert Pluim = wrote: > > > > > > On Thu, 06 Oct 2022 03:42:14 +0000, uzibalqa via "Bug reports f= or GNU Emacs, the Swiss army knife of text editors" bug-gnu-emacs@gnu.org s= aid: >=20 >=20 > uzibalqa> I am using "read-char-by-name" to read utf8 hex codes >=20 > uzibalqa> from user for input to "glasses-separator". But because >=20 > uzibalqa> "glasses-separator" requires a string I have to do >=20 > uzibalqa> (string (read-char-by-name "hex: ")). Meaning that >=20 > uzibalqa> users cannot pass "\u2192", but have to use "#x2192". >=20 > uzibalqa> Yet, using "completing-read", the list can contain >=20 > uzibalqa> "\u2192", which works fine. I am also unsure whether >=20 > uzibalqa> there is an inconsistency with >=20 > uzibalqa> display-fill-column-indicator-character which also takes >=20 > uzibalqa> unicode. >=20 >=20 > uzibalqa> Could the setting up of "glasses-separator" be >=20 > uzibalqa> simplified? Could "read-char-by-name" be extended to >=20 > uzibalqa> accept hexcodes like "\u2192", or is there some other >=20 > uzibalqa> function that can handle the different unicode inputs >=20 > uzibalqa> from minibuffer better? >=20 >=20 > I suggest you read the docstring for `read-char-by-name' more > carefully: >=20 > Accept a name like "CIRCULATION FUNCTION", a hexadecimal > number like "2A10", or a number in hash notation (e.g., > "#x2a10" for hex, "10r10768" for decimal, or "#o25020" for > octal). Treat otherwise-ambiguous strings like "BED" (U+1F6CF) > as names, not numbers. Have read the docstring. The discussion is not about the docstring. Using "\u2192" should be perfectly fine for a utf code. One often sees things like "?\u2192". After all, Emacs provides several types of escape syntax that one can use to specify non-ASCII text characters including "?\uxxxx" besides the hexadecimal character codes escape sequence=20 (See 2.4.3.2 General Escape Syntax.) For instance "glasses-separator" accepts "\u2192", yet the user cannot input the same for minibuffer input involving utf. This also applies to "display-fill-column-indicator-character" where "?\u2503" is perfectly acceptable.