GNU bug report logs - #58326
Reading unicode user inputs from minibuffer

Previous Next

Full log

View this message in rfc822 format

From: uzibalqa <uzibalqa <at> proton.me>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: 58326 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: bug#58326: Reading unicode user inputs from minibuffer
Date: Thu, 06 Oct 2022 17:52:05 +0000

------- Original Message -------
On Thursday, October 6th, 2022 at 5:21 PM, Robert Pluim <rpluim <at> gmail.com> wrote:


> > > > > > On Thu, 06 Oct 2022 16:34:01 +0000, uzibalqa uzibalqa <at> proton.me said:
> 
> 
> uzibalqa> ------- Original Message -------
> 
> uzibalqa> On Thursday, October 6th, 2022 at 12:21 PM, Lars Ingebrigtsen larsi <at> gnus.org wrote:
> 
> 
> 
> >> This doesn't seem to be about any bugs in Emacs, so I'm closing this bug
> 
> >> report.
> 
> >>
> 
> >> If you need help with using Emacs, please use the mailing lists that
> 
> >> exist for that purpose.
> 
> 
> uzibalqa> It is about limitation on not taking \uN.
> 
> 
> `read-char-by-name' accepts N or #xN, so why would it need extending
> to accept \uN?

Because \uN is also an acceptable declaration as has been used in elisp source
code in other routines.  Although accepting "N" from users is satisfactory.
At times I feel that certain decisions on what to accept and what not to accept
are completely arbitrary.  I am of the school of thought that if there are three 
valid possibilities, one could simply support the three.  Why deal with just 
two of them.         

There is also another problem, suppose one decides to use a list, passing utf codes
through "completing-read".  In such case only codes inputted as "\u25BA" would work.
Using "25BA" and "#x25BA" is futile.  These are complications that can be avoided. 

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.