bug#58326: Reading unicode user inputs from minibuffer

bug#58326: Reading unicode user inputs from minibuffer

[uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors]

I am using "read-char-by-name" to read utf8 hex codes from user for input to  "glasses-separator".
But because "glasses-separator" requires a string I have to do (string (read-char-by-name "hex: ")).
Meaning that users cannot pass "\u2192", but have to use "#x2192".  Yet, using "completing-read",
the list can contain "\u2192", which works fine.  I am also unsure whether there is an inconsistency
with display-fill-column-indicator-character which also takes unicode. 

Could the setting up of "glasses-separator" be simplified?  Could "read-char-by-name" be extended to accept
hexcodes like "\u2192", or is there some other function that can handle the different unicode inputs from minibuffer better?

-----------------------------------------------------

(defun camel-glasses (hexcode)

  "Splits CamelCase phrases using separator."

  (interactive (list (completing-read "hexcode: " '("\u27A4" "\u25BA") nil t)))

  (setq glasses-separator hexcode)

  (glasses-set-overlay-properties))

----------------------------------------------

(defun camel-glasses (hexcode)

  "Splits CamelCase phrases using separator."

  (interactive (list (string (read-char-by-name "hex: ")))

  (setq glasses-separator hexcode)

  (glasses-set-overlay-properties))

-------------------------------------

bug#58326: Reading unicode user inputs from minibuffer

[Robert Pluim]

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

Robert
-- 

bug#58326: Reading unicode user inputs from minibuffer

[uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

bug#58326: Reading unicode user inputs from minibuffer

[Lars Ingebrigtsen]

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.

bug#58326: Reading unicode user inputs from minibuffer

[uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

It is about limitation on not taking \uN.

bug#58326: Reading unicode user inputs from minibuffer

[Robert Pluim]

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

Robert
-- 

bug#58326: Reading unicode user inputs from minibuffer

[uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

bug#58326: Reading unicode user inputs from minibuffer

[uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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