bug#58326: Reading unicode user inputs from minibuffer

[uzibalqa]

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


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