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

Previous Next

Full log

Message #30 received at 58326 <at> debbugs.gnu.org (full text, mbox):

From: uzibalqa <uzibalqa <at> proton.me>
To: uzibalqa <uzibalqa <at> proton.me>
Cc: 58326 <at> debbugs.gnu.org, Robert Pluim <rpluim <at> gmail.com>,
 Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#58326: Reading unicode user inputs from minibuffer
Date: Fri, 07 Oct 2022 00:45:45 +0000

------- Original Message -------
On Thursday, October 6th, 2022 at 5:52 PM, uzibalqa via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org> wrote:


> ------- 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.

There is some serious inconsistency because 

I can do (code (completing-read "Opt: " '("\u27A4") nil t))) (setq glasses-separator code).
This works, but fails with "#x27A4".  

But then for read-char-by-name
(code (string (read-char-by-name "Opt: "))) (setq glasses-separator code)
This works with "#x27A4", but fails with "\u27A4"

(setq glasses-separator code) accepts a string, whether "\u27A4" or "#x27A4", but minibuffer
input is affected by which call is used "completing-read" or "read-char-by-name".

Previous Next

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