bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#58326: Reading unicode user inputs from minibuffer


From: uzibalqa
Subject: 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@gnu.org> wrote:


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

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










reply via email to

[Prev in Thread] Current Thread [Next in Thread]