bug#58326: Reading unicode user inputs from minibuffer

[uzibalqa]

------- Original Message -------
On Thursday, October 6th, 2022 at 8:45 AM, Robert Pluim <rpluim@gmail.com> 
wrote:


> > > > > > On Thu, 06 Oct 2022 03:42:14 +0000, uzibalqa via "Bug reports for 
> > > > > > GNU Emacs, the Swiss army knife of text editors" 
> > > > > > bug-gnu-emacs@gnu.org said:
> 
> 
> uzibalqa> I am using "read-char-by-name" to read utf8 hex codes
> 
> uzibalqa> from user for input to "glasses-separator". But because
> 
> uzibalqa> "glasses-separator" requires a string I have to do
> 
> uzibalqa> (string (read-char-by-name "hex: ")). Meaning that
> 
> uzibalqa> users cannot pass "\u2192", but have to use "#x2192".
> 
> uzibalqa> Yet, using "completing-read", the list can contain
> 
> uzibalqa> "\u2192", which works fine. I am also unsure whether
> 
> uzibalqa> there is an inconsistency with
> 
> uzibalqa> display-fill-column-indicator-character which also takes
> 
> uzibalqa> unicode.
> 
> 
> uzibalqa> Could the setting up of "glasses-separator" be
> 
> uzibalqa> simplified? Could "read-char-by-name" be extended to
> 
> uzibalqa> accept hexcodes like "\u2192", or is there some other
> 
> uzibalqa> function that can handle the different unicode inputs
> 
> uzibalqa> from minibuffer better?
> 
> 
> I suggest you read the docstring for `read-char-by-name' more
> carefully:
> 
> Accept a name like "CIRCULATION FUNCTION", a hexadecimal
> number like "2A10", or a number in hash notation (e.g.,
> "#x2a10" for hex, "10r10768" for decimal, or "#o25020" for
> octal). Treat otherwise-ambiguous strings like "BED" (U+1F6CF)
> as names, not numbers.

Have read the docstring.  The discussion is not about the docstring.
Using "\u2192" should be perfectly fine for a utf code.  One often sees
things like "?\u2192".  After all, Emacs provides several types of escape
syntax that one can use to specify non-ASCII text characters including
"?\uxxxx" besides the hexadecimal character codes escape sequence 
(See 2.4.3.2 General Escape Syntax.)

For instance "glasses-separator" accepts "\u2192", yet the user cannot
input the same for minibuffer input involving utf.  This also applies to
"display-fill-column-indicator-character" where "?\u2503" is perfectly
acceptable.