* bug#58326: Reading unicode user inputs from minibuffer @ 2022-10-06 3:42 uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors 2022-10-06 8:45 ` Robert Pluim 0 siblings, 1 reply; 8+ messages in thread From: uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-10-06 3:42 UTC (permalink / raw) To: 58326 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)) ------------------------------------- ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#58326: Reading unicode user inputs from minibuffer 2022-10-06 3:42 bug#58326: Reading unicode user inputs from minibuffer uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-10-06 8:45 ` Robert Pluim 2022-10-06 11:51 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors 0 siblings, 1 reply; 8+ messages in thread From: Robert Pluim @ 2022-10-06 8:45 UTC (permalink / raw) To: 58326; +Cc: uzibalqa >>>>> 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 -- ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#58326: Reading unicode user inputs from minibuffer 2022-10-06 8:45 ` Robert Pluim @ 2022-10-06 11:51 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors 2022-10-06 12:21 ` Lars Ingebrigtsen 0 siblings, 1 reply; 8+ messages in thread From: uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-10-06 11:51 UTC (permalink / raw) To: Robert Pluim; +Cc: 58326 ------- 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#58326: Reading unicode user inputs from minibuffer 2022-10-06 11:51 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-10-06 12:21 ` Lars Ingebrigtsen 2022-10-06 16:34 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors 0 siblings, 1 reply; 8+ messages in thread From: Lars Ingebrigtsen @ 2022-10-06 12:21 UTC (permalink / raw) To: uzibalqa; +Cc: 58326, Robert Pluim 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#58326: Reading unicode user inputs from minibuffer 2022-10-06 12:21 ` Lars Ingebrigtsen @ 2022-10-06 16:34 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors 2022-10-06 17:21 ` Robert Pluim 0 siblings, 1 reply; 8+ messages in thread From: uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-10-06 16:34 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 58326, Robert Pluim ------- 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#58326: Reading unicode user inputs from minibuffer 2022-10-06 16:34 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-10-06 17:21 ` Robert Pluim 2022-10-06 17:52 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors 0 siblings, 1 reply; 8+ messages in thread From: Robert Pluim @ 2022-10-06 17:21 UTC (permalink / raw) To: uzibalqa; +Cc: 58326, Lars Ingebrigtsen >>>>> 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 -- ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#58326: Reading unicode user inputs from minibuffer 2022-10-06 17:21 ` Robert Pluim @ 2022-10-06 17:52 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors 2022-10-07 0:45 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors 0 siblings, 1 reply; 8+ messages in thread From: uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-10-06 17:52 UTC (permalink / raw) To: Robert Pluim; +Cc: 58326, Lars Ingebrigtsen ------- 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#58326: Reading unicode user inputs from minibuffer 2022-10-06 17:52 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-10-07 0:45 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors 0 siblings, 0 replies; 8+ messages in thread From: uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-10-07 0:45 UTC (permalink / raw) To: uzibalqa; +Cc: 58326, Robert Pluim, Lars Ingebrigtsen ------- 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". ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2022-10-07 0:45 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-10-06 3:42 bug#58326: Reading unicode user inputs from minibuffer uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors 2022-10-06 8:45 ` Robert Pluim 2022-10-06 11:51 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors 2022-10-06 12:21 ` Lars Ingebrigtsen 2022-10-06 16:34 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors 2022-10-06 17:21 ` Robert Pluim 2022-10-06 17:52 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors 2022-10-07 0:45 ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.