Subject: Re: bug#58326: Reading unicode user inputs from minibuffer

From: uzibalqa <[email-masked]>
Date: Thu, 06 Oct 2022 17:52:05 +0000

------- Original Message -------
On Thursday, October 6th, 2022 at 5:21 PM, Robert Pluim <[email-masked]> wrote:

> > > > > > On Thu, 06 Oct 2022 16:34:01 +0000, uzibalqa [email-masked] said:
> 
> 
> uzibalqa> ------- Original Message -------
> 
> uzibalqa> On Thursday, October 6th, 2022 at 12:21 PM, Lars Ingebrigtsen [email-masked] 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.