Re: emacs-28 a866674b2a: Fix inaccuracies in "lax search" documentation

Re: emacs-28 a866674b2a: Fix inaccuracies in "lax search" documentation

[Robert Pluim]

>>>>> On Mon, 25 Jul 2022 08:01:42 -0400 (EDT), Eli Zaretskii <eliz@gnu.org> said:
    Eli> +@sc{latin small ligature ff} and the sequence @code{(a)} matches
    Eli> +U+249C @sc{parenthesized latin small letter a}.  Character sequences
    Eli> +that are not identical, but match under character folding are known as
    Eli> +@dfn{equivalent character sequences}.

Should we make `char-fold-to-regexp' into a command and refer to it
from here? Or add something like `char-fold-show-equivalences'?

Robert
-- 

Re: emacs-28 a866674b2a: Fix inaccuracies in "lax search" documentation

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>
> Gmane-Reply-To-List: yes
> Date: Mon, 25 Jul 2022 15:01:38 +0200
> 
> Should we make `char-fold-to-regexp' into a command and refer to it
> from here? Or add something like `char-fold-show-equivalences'?

I'm not sure I understand what you have in mind, but if the intent is
to allow easier customization of char-fold.el, I'm for it.  I'd also
welcome commands for displaying the equivalent sequences in an easily
readable format, although that could be a non-trivial job.

Re: emacs-28 a866674b2a: Fix inaccuracies in "lax search" documentation

[Robert Pluim]

>>>>> On Mon, 25 Jul 2022 16:43:59 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Cc: Eli Zaretskii <eliz@gnu.org>
    >> Gmane-Reply-To-List: yes
    >> Date: Mon, 25 Jul 2022 15:01:38 +0200
    >> 
    >> Should we make `char-fold-to-regexp' into a command and refer to it
    >> from here? Or add something like `char-fold-show-equivalences'?

    Eli> I'm not sure I understand what you have in mind, but if the intent is
    Eli> to allow easier customization of char-fold.el, I'm for it.  I'd also
    Eli> welcome commands for displaying the equivalent sequences in an easily
    Eli> readable format, although that could be a non-trivial job.

I initially was thinking just of showing the regexp, but youʼd want to
show each individial char? ie, instead of

"\\(?:\\(?:ḟ\\|[fᶠḟⓕｆ𝐟𝑓𝒇𝒻𝓯𝔣𝕗𝖋𝖿𝗳𝘧𝙛𝚏]\\)\\|ffl\\|ffi\\|fl\\|fi\\|ff\\|㎙\\|ḟ\\)"

show something like:

Characters quivalent to: 'f'

 𝚏
 𝙛
 𝘧
 𝗳
 𝖿
 𝖋
 𝕗
 𝔣
 𝓯
 𝒻
 𝒇
 𝑓
 𝐟
 ｆ
 Ｆ
 ffl
 ffi
 fl
 fi
 ff
 ㎙
 ㎙
 ⓕ
 Ⓕ
 ḟ
 Ḟ
 ᶠ
 f
 F

etc? Getting that list is relatively easy, itʼs the bike shedding
about the format that will be hard (and what to do with
`case-fold-search') :-)


Robert
-- 

Re: emacs-28 a866674b2a: Fix inaccuracies in "lax search" documentation

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Mon, 25 Jul 2022 16:48:28 +0200
> 
> I initially was thinking just of showing the regexp, but youʼd want to
> show each individial char? ie, instead of
> 
> "\\(?:\\(?:ḟ\\|[fᶠḟⓕｆ𝐟𝑓𝒇𝒻𝓯𝔣𝕗𝖋𝖿𝗳𝘧𝙛𝚏]\\)\\|ffl\\|ffi\\|fl\\|fi\\|ff\\|㎙\\|ḟ\\)"
> 
> show something like:
> 
> Characters quivalent to: 'f'
> 
>  𝚏
>  𝙛
>  𝘧

Yes, something like that.

But note that, for example, ffl is NOT equivalent to 'f', so I think
you'd need to separate the stuff in extra-slot from the stuff in the
char-table itself.

Re: emacs-28 a866674b2a: Fix inaccuracies in "lax search" documentation

[Robert Pluim]

>>>>> On Mon, 25 Jul 2022 16:43:59 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Cc: Eli Zaretskii <eliz@gnu.org>
    >> Gmane-Reply-To-List: yes
    >> Date: Mon, 25 Jul 2022 15:01:38 +0200
    >> 
    >> Should we make `char-fold-to-regexp' into a command and refer to it
    >> from here? Or add something like `char-fold-show-equivalences'?

    Eli> I'm not sure I understand what you have in mind, but if the intent is
    Eli> to allow easier customization of char-fold.el, I'm for it.

I didnʼt pick up on this earlier. What do you mean by "easier
customization of char-fold.el"? I thought the various include/exclude
vars were all customizable already?

Robert
-- 

Re: emacs-28 a866674b2a: Fix inaccuracies in "lax search" documentation

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Tue, 26 Jul 2022 14:52:25 +0200
> 
> >>>>> On Mon, 25 Jul 2022 16:43:59 +0300, Eli Zaretskii <eliz@gnu.org> said:
> 
>     >> From: Robert Pluim <rpluim@gmail.com>
>     >> Cc: Eli Zaretskii <eliz@gnu.org>
>     >> Gmane-Reply-To-List: yes
>     >> Date: Mon, 25 Jul 2022 15:01:38 +0200
>     >> 
>     >> Should we make `char-fold-to-regexp' into a command and refer to it
>     >> from here? Or add something like `char-fold-show-equivalences'?
> 
>     Eli> I'm not sure I understand what you have in mind, but if the intent is
>     Eli> to allow easier customization of char-fold.el, I'm for it.
> 
> I didnʼt pick up on this earlier. What do you mean by "easier
> customization of char-fold.el"? I thought the various include/exclude
> vars were all customizable already?

Yes, but the values are not very friendly for interactive
customizations, IMNSHO.

Anyway, if you didn't mean to do anything about that, I'm okay with
the status quo.

Re: emacs-28 a866674b2a: Fix inaccuracies in "lax search" documentation

[Robert Pluim]

>>>>> On Tue, 26 Jul 2022 16:16:35 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> I didnʼt pick up on this earlier. What do you mean by "easier
    >> customization of char-fold.el"? I thought the various include/exclude
    >> vars were all customizable already?

    Eli> Yes, but the values are not very friendly for interactive
    Eli> customizations, IMNSHO.

Theyʼre fundamentally mappings from a base char to a set of
'equivalent' chars. You can use 'C-x 8 RET' to enter any of them, and
you can delete the entries for a base char easily, so I guess Iʼm
missing the difficulty (but then UX is always very personal).

Robert
-- 

Re: emacs-28 a866674b2a: Fix inaccuracies in "lax search" documentation

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Tue, 26 Jul 2022 16:23:47 +0200
> 
> >>>>> On Tue, 26 Jul 2022 16:16:35 +0300, Eli Zaretskii <eliz@gnu.org> said:
> 
>     >> I didnʼt pick up on this earlier. What do you mean by "easier
>     >> customization of char-fold.el"? I thought the various include/exclude
>     >> vars were all customizable already?
> 
>     Eli> Yes, but the values are not very friendly for interactive
>     Eli> customizations, IMNSHO.
> 
> Theyʼre fundamentally mappings from a base char to a set of
> 'equivalent' chars. You can use 'C-x 8 RET' to enter any of them, and
> you can delete the entries for a base char easily, so I guess Iʼm
> missing the difficulty (but then UX is always very personal).

Well, one question that it would be nice to be able to ask Emacs is
"show me all the characters that resemble CH", so that users could
decide what to add to the existing set.

Another potential issue is how does one easily delete a character from
the list, when what is known is its name or codepoint?  Using Isearch
with \N{...} or "C-x 8 RET" is quite advanced.

Re: emacs-28 a866674b2a: Fix inaccuracies in "lax search" documentation

[Robert Pluim]

>>>>> On Tue, 26 Jul 2022 19:06:25 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Cc: emacs-devel@gnu.org
    >> Date: Tue, 26 Jul 2022 16:23:47 +0200
    >> 
    >> >>>>> On Tue, 26 Jul 2022 16:16:35 +0300, Eli Zaretskii <eliz@gnu.org> said:
    >> 
    >> >> I didnʼt pick up on this earlier. What do you mean by "easier
    >> >> customization of char-fold.el"? I thought the various include/exclude
    >> >> vars were all customizable already?
    >> 
    Eli> Yes, but the values are not very friendly for interactive
    Eli> customizations, IMNSHO.
    >> 
    >> Theyʼre fundamentally mappings from a base char to a set of
    >> 'equivalent' chars. You can use 'C-x 8 RET' to enter any of them, and
    >> you can delete the entries for a base char easily, so I guess Iʼm
    >> missing the difficulty (but then UX is always very personal).

    Eli> Well, one question that it would be nice to be able to ask Emacs is
    Eli> "show me all the characters that resemble CH", so that users could
    Eli> decide what to add to the existing set.

But the characters that resemble CH are already in the char-fold-table
by default. And "chars that look like CH but arenʼt in the
char-fold-table" is something that a human can determine, but Iʼm all
out of ideas on how to do it in elisp.

    Eli> Another potential issue is how does one easily delete a character from
    Eli> the list, when what is known is its name or codepoint?  Using Isearch
    Eli> with \N{...} or "C-x 8 RET" is quite advanced.

That sounds like we need a custom custom widget. I took a quick look,
but I didnʼt see an obvious way to have a widget which could display
its value(s) in several different formats.

Robert
-- 

Re: emacs-28 a866674b2a: Fix inaccuracies in "lax search" documentation

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Tue, 26 Jul 2022 18:54:38 +0200
> 
>     Eli> Well, one question that it would be nice to be able to ask Emacs is
>     Eli> "show me all the characters that resemble CH", so that users could
>     Eli> decide what to add to the existing set.
> 
> But the characters that resemble CH are already in the char-fold-table
> by default.

No, only those which we considered "safe" enough and which our
heuristic collected.  For example, ⒜ is by default not considered
resembling 'a'.

> And "chars that look like CH but arenʼt in the
> char-fold-table" is something that a human can determine, but Iʼm all
> out of ideas on how to do it in elisp.

Look for characters whose decomposition has CH anywhere in the list?

>     Eli> Another potential issue is how does one easily delete a character from
>     Eli> the list, when what is known is its name or codepoint?  Using Isearch
>     Eli> with \N{...} or "C-x 8 RET" is quite advanced.
> 
> That sounds like we need a custom custom widget. I took a quick look,
> but I didnʼt see an obvious way to have a widget which could display
> its value(s) in several different formats.

Like I said, I'm okay with status quo.

Thanks.

Re: emacs-28 a866674b2a: Fix inaccuracies in "lax search" documentation

[Robert Pluim]

>>>>> On Tue, 26 Jul 2022 20:15:02 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Cc: emacs-devel@gnu.org
    >> Date: Tue, 26 Jul 2022 18:54:38 +0200
    >> 
    Eli> Well, one question that it would be nice to be able to ask Emacs is
    Eli> "show me all the characters that resemble CH", so that users could
    Eli> decide what to add to the existing set.
    >> 
    >> But the characters that resemble CH are already in the char-fold-table
    >> by default.

    Eli> No, only those which we considered "safe" enough and which our
    Eli> heuristic collected.  For example, ⒜ is by default not considered
    Eli> resembling 'a'.

OK

    >> And "chars that look like CH but arenʼt in the
    >> char-fold-table" is something that a human can determine, but Iʼm all
    >> out of ideas on how to do it in elisp.

    Eli> Look for characters whose decomposition has CH anywhere in the list?

I thought we already did that, but it looks like we only look at the
first char in the decomposition.

Robert
-- 

Re: emacs-28 a866674b2a: Fix inaccuracies in "lax search" documentation

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Wed, 27 Jul 2022 09:54:41 +0200
> 
> >>>>> On Tue, 26 Jul 2022 20:15:02 +0300, Eli Zaretskii <eliz@gnu.org> said:
> 
>     Eli> Well, one question that it would be nice to be able to ask Emacs is
>     Eli> "show me all the characters that resemble CH", so that users could
>     Eli> decide what to add to the existing set.
>     >> 
>     >> But the characters that resemble CH are already in the char-fold-table
>     >> by default.
> 
>     Eli> No, only those which we considered "safe" enough and which our
>     Eli> heuristic collected.  For example, ⒜ is by default not considered
>     Eli> resembling 'a'.
> 
> OK
> 
>     >> And "chars that look like CH but arenʼt in the
>     >> char-fold-table" is something that a human can determine, but Iʼm all
>     >> out of ideas on how to do it in elisp.
> 
>     Eli> Look for characters whose decomposition has CH anywhere in the list?
> 
> I thought we already did that, but it looks like we only look at the
> first char in the decomposition.

Yes.

Re: emacs-28 a866674b2a: Fix inaccuracies in "lax search" documentation

[Juri Linkov]

>> +@sc{latin small ligature ff} and the sequence @code{(a)} matches
>> +U+249C @sc{parenthesized latin small letter a}.  Character sequences
>> +that are not identical, but match under character folding are known as
>> +@dfn{equivalent character sequences}.
>
> Should we make `char-fold-to-regexp' into a command and refer to it
> from here? Or add something like `char-fold-show-equivalences'?

A better name would be `describe-char-fold'.  Then in outlines,
the outline heading could show the character with its name,
and the outline body a list of characters it matches, with names.

Re: emacs-28 a866674b2a: Fix inaccuracies in "lax search" documentation

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: emacs-devel@gnu.org,  Eli Zaretskii <eliz@gnu.org>
> Date: Mon, 25 Jul 2022 20:52:08 +0300
> 
> > Should we make `char-fold-to-regexp' into a command and refer to it
> > from here? Or add something like `char-fold-show-equivalences'?
> 
> A better name would be `describe-char-fold'.

For a command, I'd say describe-character-foldings.  But
char-fold-show-equivalences is IMO a better name.

Re: emacs-28 a866674b2a: Fix inaccuracies in "lax search" documentation

[Juri Linkov]

>> > Should we make `char-fold-to-regexp' into a command and refer to it
>> > from here? Or add something like `char-fold-show-equivalences'?
>>
>> A better name would be `describe-char-fold'.
>
> For a command, I'd say describe-character-foldings.  But
> char-fold-show-equivalences is IMO a better name.

All similar commands have names starting with the `describe-' prefix like
`describe-char', `describe-character-set'.  So maybe then
`describe-char-fold-equivalences'.

Re: emacs-28 a866674b2a: Fix inaccuracies in "lax search" documentation

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 542 bytes --]

>>> > Should we make `char-fold-to-regexp' into a command and refer to it
>>> > from here? Or add something like `char-fold-show-equivalences'?
>>>
>>> A better name would be `describe-char-fold'.
>>
>> For a command, I'd say describe-character-foldings.  But
>> char-fold-show-equivalences is IMO a better name.
>
> All similar commands have names starting with the `describe-' prefix like
> `describe-char', `describe-character-set'.  So maybe then
> `describe-char-fold-equivalences'.

Ok, then let's use describe-char-fold-equivalences:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: describe-char-fold-equivalences.patch --]
[-- Type: text/x-diff, Size: 2202 bytes --]

diff --git a/lisp/char-fold.el b/lisp/char-fold.el
index 05ae52cae0..71a1fb1910 100644
--- a/lisp/char-fold.el
+++ b/lisp/char-fold.el
@@ -48,6 +48,7 @@
 
 \f
 (eval-and-compile
+  (defvar char-fold--no-regexp nil)
   (defun char-fold--make-table ()
     (let* ((equiv (make-char-table 'char-fold-table))
            (equiv-multi (make-char-table 'char-fold-table))
@@ -201,11 +202,14 @@
            symmetric)))
 
       ;; Convert the lists of characters we compiled into regexps.
-      (map-char-table
-       (lambda (char decomp-list)
-         (let ((re (regexp-opt (cons (char-to-string char) decomp-list))))
-           (aset equiv char re)))
-       equiv)
+      (unless char-fold--no-regexp
+        ;; Non-nil `char-fold--no-regexp' unoptimized for regexp
+        ;; is used by `describe-char-fold-equivalences'.
+        (map-char-table
+         (lambda (char decomp-list)
+           (let ((re (regexp-opt (cons (char-to-string char) decomp-list))))
+             (aset equiv char re)))
+         equiv))
       equiv)))
 
 (defconst char-fold-table
@@ -421,6 +425,28 @@ char-fold-search-backward
   (interactive "sSearch: ")
   (re-search-backward (char-fold-to-regexp string) bound noerror count))
 
+\f
+(defun describe-char-fold-equivalences ()
+  "Describe character equivalences of `char-fold-to-regexp'."
+  (interactive)
+  (require 'help-fns)
+  (let ((help-buffer-under-preparation t))
+    (help-setup-xref (list #'describe-char-fold-equivalences)
+                     (called-interactively-p 'interactive))
+    (let ((equivalences nil))
+      (map-char-table
+       (lambda (char list)
+         (setq equivalences (cons (cons char list) equivalences)))
+       (let ((char-fold--no-regexp t))
+         (char-fold--make-table)))
+      (with-help-window (help-buffer)
+        (with-current-buffer standard-output
+          (insert "A list char-fold equivalences for `char-fold-to-regexp'.\n\n")
+          (dolist (equiv (nreverse equivalences))
+            (insert (format "%c: %s\n" (car equiv)
+                            (mapconcat #'identity (cdr equiv)
+                                       " ")))))))))
+
 (provide 'char-fold)
 
 ;;; char-fold.el ends here

Re: emacs-28 a866674b2a: Fix inaccuracies in "lax search" documentation

[Robert Pluim]

>>>>> On Mon, 25 Jul 2022 22:49:11 +0300, Juri Linkov <juri@linkov.net> said:

    >>>> > Should we make `char-fold-to-regexp' into a command and refer to it
    >>>> > from here? Or add something like `char-fold-show-equivalences'?
    >>>> 
    >>>> A better name would be `describe-char-fold'.
    >>> 
    >>> For a command, I'd say describe-character-foldings.  But
    >>> char-fold-show-equivalences is IMO a better name.
    >> 
    >> All similar commands have names starting with the `describe-' prefix like
    >> `describe-char', `describe-character-set'.  So maybe then
    >> `describe-char-fold-equivalences'.

    Juri> Ok, then let's use describe-char-fold-equivalences:

Ah, that lists *all* the equivalences. I was thinking more along the
lines of the following (we can give it a different name, or combine them)

(defun char-fold-char-equivalences (char &optional lax)
  "Display characters equivalent to CHAR.
Prompt for CHAR.  Interactively, a prefix arg means also include
any ligatures that CHAR partially matches."
  (interactive (list (read-char-by-name "Character (Unicode name or hex): ")
                     current-prefix-arg))
  (require 'help-fns)
  (let ((help-buffer-under-preparation t))
    (help-setup-xref (list #'describe-char-fold-equivalences)
                     (called-interactively-p 'interactive))
    (let* ((equivalences nil)
           (char-fold--no-regexp t)
           (table (char-fold--make-table))
           (extra (aref (char-table-extra-slot table 0) char)))
      (setq equivalences (aref table char))
      (when lax
        (setq equivalences (append equivalences
                                 (mapcar (lambda (entry)
                                           (cdr entry))
                                         extra))))
      (setq equivalences (cons (char-to-string char) equivalences))
      (with-help-window (help-buffer)
        (with-current-buffer standard-output
          (insert (mapconcat
                   (lambda (c)
                     (format "%s: \?\\N{%s}\n"
                             c
                             (or (get-char-code-property (string-to-char c) 'name)
                                 (get-char-code-property (string-to-char c) 'old-name))))
                   equivalences)))))))

Robert
-- 

Re: emacs-28 a866674b2a: Fix inaccuracies in "lax search" documentation

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Tue, 26 Jul 2022 09:59:07 +0200
> 
> >>>>> On Mon, 25 Jul 2022 22:49:11 +0300, Juri Linkov <juri@linkov.net> said:
> 
>     Juri> Ok, then let's use describe-char-fold-equivalences:
> 
> Ah, that lists *all* the equivalences. I was thinking more along the
> lines of the following (we can give it a different name, or combine them)

I indeed think we should only show the equivalence sequences of a
single character.  Showing all of them is too much.

Re: emacs-28 a866674b2a: Fix inaccuracies in "lax search" documentation

[Juri Linkov]

>>> Ok, then let's use describe-char-fold-equivalences:
>>
>> Ah, that lists *all* the equivalences. I was thinking more along the
>> lines of the following (we can give it a different name, or combine them)
>
> I indeed think we should only show the equivalence sequences of a
> single character.  Showing all of them is too much.

Why the user should not be allowed to see all active equivalences?

Re: emacs-28 a866674b2a: Fix inaccuracies in "lax search" documentation

[Robert Pluim]

>>>>> On Wed, 27 Jul 2022 10:46:27 +0300, Juri Linkov <juri@linkov.net> said:

    >>>> Ok, then let's use describe-char-fold-equivalences:
    >>> 
    >>> Ah, that lists *all* the equivalences. I was thinking more along the
    >>> lines of the following (we can give it a different name, or combine them)
    >> 
    >> I indeed think we should only show the equivalence sequences of a
    >> single character.  Showing all of them is too much.

    Juri> Why the user should not be allowed to see all active equivalences?

We can always add an 'all' argument, but most people would be
searching for the equivalences for a particular character, I thought
(I have no evidence for this, but it seems like the obvious use-case).

Robert
-- 

Re: emacs-28 a866674b2a: Fix inaccuracies in "lax search" documentation

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Wed, 27 Jul 2022 10:13:20 +0200
> 
> >>>>> On Wed, 27 Jul 2022 10:46:27 +0300, Juri Linkov <juri@linkov.net> said:
> 
>     >>>> Ok, then let's use describe-char-fold-equivalences:
>     >>> 
>     >>> Ah, that lists *all* the equivalences. I was thinking more along the
>     >>> lines of the following (we can give it a different name, or combine them)
>     >> 
>     >> I indeed think we should only show the equivalence sequences of a
>     >> single character.  Showing all of them is too much.
> 
>     Juri> Why the user should not be allowed to see all active equivalences?
> 
> We can always add an 'all' argument, but most people would be
> searching for the equivalences for a particular character, I thought
> (I have no evidence for this, but it seems like the obvious use-case).

That was also my impression.

Re: emacs-28 a866674b2a: Fix inaccuracies in "lax search" documentation

[Juri Linkov]

>> Why the user should not be allowed to see all active equivalences?
>
> We can always add an 'all' argument, but most people would be
> searching for the equivalences for a particular character, I thought
> (I have no evidence for this, but it seems like the obvious use-case).

Wouldn't it be more natural instead of a special argument 'all'
to add a 'char' argument that will describe the equivalences
for a particular character, and when 'nil' then will describe
all characters.

Re: emacs-28 a866674b2a: Fix inaccuracies in "lax search" documentation

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Wed, 27 Jul 2022 21:54:44 +0300
> 
> >> Why the user should not be allowed to see all active equivalences?
> >
> > We can always add an 'all' argument, but most people would be
> > searching for the equivalences for a particular character, I thought
> > (I have no evidence for this, but it seems like the obvious use-case).
> 
> Wouldn't it be more natural instead of a special argument 'all'
> to add a 'char' argument that will describe the equivalences
> for a particular character, and when 'nil' then will describe
> all characters.

Only if we believe that most users will want 'all'.

Re: emacs-28 a866674b2a: Fix inaccuracies in "lax search" documentation

[Juri Linkov]

>> >> Why the user should not be allowed to see all active equivalences?
>> >
>> > We can always add an 'all' argument, but most people would be
>> > searching for the equivalences for a particular character, I thought
>> > (I have no evidence for this, but it seems like the obvious use-case).
>>
>> Wouldn't it be more natural instead of a special argument 'all'
>> to add a 'char' argument that will describe the equivalences
>> for a particular character, and when 'nil' then will describe
>> all characters.
>
> Only if we believe that most users will want 'all'.

Do we believe that most users want only describe-key,
but not describe-bindings that describes all keys?

Re: emacs-28 a866674b2a: Fix inaccuracies in "lax search" documentation

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: rpluim@gmail.com,  emacs-devel@gnu.org
> Date: Wed, 27 Jul 2022 22:55:15 +0300
> 
> >> >> Why the user should not be allowed to see all active equivalences?
> >> >
> >> > We can always add an 'all' argument, but most people would be
> >> > searching for the equivalences for a particular character, I thought
> >> > (I have no evidence for this, but it seems like the obvious use-case).
> >>
> >> Wouldn't it be more natural instead of a special argument 'all'
> >> to add a 'char' argument that will describe the equivalences
> >> for a particular character, and when 'nil' then will describe
> >> all characters.
> >
> > Only if we believe that most users will want 'all'.
> 
> Do we believe that most users want only describe-key,
> but not describe-bindings that describes all keys?

That analogy is lost on me.

Character equivalences exist for many characters, so showing all of
them by default is not necessarily TRT.  I remind you that with
describe-bindings, we need to use outline-minor-mode to make the
result reasonably legible, for that very reason.

Re: emacs-28 a866674b2a: Fix inaccuracies in "lax search" documentation

[Eli Zaretskii]

> Date: Thu, 28 Jul 2022 08:40:57 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: rpluim@gmail.com, emacs-devel@gnu.org
> 
> Character equivalences exist for many characters, so showing all of
> them by default is not necessarily TRT.  I remind you that with
> describe-bindings, we need to use outline-minor-mode to make the
> result reasonably legible, for that very reason.

Also, we do have describe-key and describe-bindings, which are two
separate commands that produce very different outputs.  It would be
okay to have 2 separate commands here as well, but AFAIU that was not
your proposal.

Re: emacs-28 a866674b2a: Fix inaccuracies in "lax search" documentation

[Juri Linkov]

> Also, we do have describe-key and describe-bindings, which are two
> separate commands that produce very different outputs.  It would be
> okay to have 2 separate commands here as well, but AFAIU that was not
> your proposal.

My proposal is to have one command that depending on the prefix argument
will either show equivalences of all characters, or will read a character
name to display its equivalences only.

Re: emacs-28 a866674b2a: Fix inaccuracies in "lax search" documentation

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: rpluim@gmail.com,  emacs-devel@gnu.org
> Date: Thu, 28 Jul 2022 10:13:07 +0300
> 
> > Also, we do have describe-key and describe-bindings, which are two
> > separate commands that produce very different outputs.  It would be
> > okay to have 2 separate commands here as well, but AFAIU that was not
> > your proposal.
> 
> My proposal is to have one command that depending on the prefix argument
> will either show equivalences of all characters, or will read a character
> name to display its equivalences only.

This is less convenient than two separate commands, IMO.

Re: emacs-28 a866674b2a: Fix inaccuracies in "lax search" documentation

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 381 bytes --]

> Character equivalences exist for many characters, so showing all of
> them by default is not necessarily TRT.  I remind you that with
> describe-bindings, we need to use outline-minor-mode to make the
> result reasonably legible, for that very reason.

No need to use outlines.  The output looks nice
with plain lists where 'C-x =' can be used on any
character to get its name:


[-- Attachment #2: describe-char-fold-equivalences.png --]
[-- Type: image/png, Size: 80882 bytes --]

Re: emacs-28 a866674b2a: Fix inaccuracies in "lax search" documentation

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: rpluim@gmail.com,  emacs-devel@gnu.org
> Date: Thu, 28 Jul 2022 10:10:44 +0300
> 
> > Character equivalences exist for many characters, so showing all of
> > them by default is not necessarily TRT.  I remind you that with
> > describe-bindings, we need to use outline-minor-mode to make the
> > result reasonably legible, for that very reason.
> 
> No need to use outlines.  The output looks nice
> with plain lists where 'C-x =' can be used on any
> character to get its name:

How long is the list?

And what happens if the user customizes char-fold.el to add more
equivalent sequences?

And once again, why not have two separate commands, one for each use
case?

Re: emacs-28 a866674b2a: Fix inaccuracies in "lax search" documentation

[Juri Linkov]

>> No need to use outlines.  The output looks nice
>> with plain lists where 'C-x =' can be used on any
>> character to get its name:
>
> How long is the list?
>
> And what happens if the user customizes char-fold.el to add more
> equivalent sequences?

I have a huge list of 6682 customized equivalences, and there is
no problem with displaying all of them.

> And once again, why not have two separate commands, one for each use
> case?

It's fine to have two separate commands, maybe with names like:

  M-x describe-char-fold-equivalence
  M-x describe-char-fold-equivalences

Re: emacs-28 a866674b2a: Fix inaccuracies in "lax search" documentation

[Juri Linkov]

>     >>>> > Should we make `char-fold-to-regexp' into a command and refer to it
>     >>>> > from here? Or add something like `char-fold-show-equivalences'?
>     >>>>
>     >>>> A better name would be `describe-char-fold'.
>     >>>
>     >>> For a command, I'd say describe-character-foldings.  But
>     >>> char-fold-show-equivalences is IMO a better name.
>     >>
>     >> All similar commands have names starting with the `describe-' prefix like
>     >> `describe-char', `describe-character-set'.  So maybe then
>     >> `describe-char-fold-equivalences'.
>
>     Juri> Ok, then let's use describe-char-fold-equivalences:
>
> Ah, that lists *all* the equivalences. I was thinking more along the
> lines of the following (we can give it a different name, or combine them)

The new command 'describe-char-fold-equivalences' that combines both
approaches is pushed now.  Thanks for helping to add this useful feature.

Re: emacs-28 a866674b2a: Fix inaccuracies in "lax search" documentation

[Robert Pluim]

>>>>> On Tue, 30 Aug 2022 10:29:08 +0300, Juri Linkov <juri@linkov.net> said:

    >> Ah, that lists *all* the equivalences. I was thinking more along the
    >> lines of the following (we can give it a different name, or combine them)

    Juri> The new command 'describe-char-fold-equivalences' that combines both
    Juri> approaches is pushed now.  Thanks for helping to add this useful feature.

Thanks for that. I have one comment: using `read-char-by-name' is kind
of cumbersome when all you want to do is find the equivalents to
e.g. 'a'. Would it make sense to have something similar to
`read-char-by-name' but that accepted single characters *without*
treating those as hex? Youʼd still be able to enter single digit
hex characters by prefixing them with '0'.

Robert
-- 

Re: emacs-28 a866674b2a: Fix inaccuracies in "lax search" documentation

[Juri Linkov]

> I have one comment: using `read-char-by-name' is kind
> of cumbersome when all you want to do is find the equivalents to
> e.g. 'a'. Would it make sense to have something similar to
> `read-char-by-name' but that accepted single characters *without*
> treating those as hex? Youʼd still be able to enter single digit
> hex characters by prefixing them with '0'.

Wouldn't it be cleaner to use just (read-char-from-minibuffer "Character: ")
where you can either type a character directly or use 'C-x 8 RET'
to insert a character by its name.

Re: emacs-28 a866674b2a: Fix inaccuracies in "lax search" documentation

[Robert Pluim]

>>>>> On Wed, 31 Aug 2022 19:09:34 +0300, Juri Linkov <juri@linkov.net> said:

    >> I have one comment: using `read-char-by-name' is kind
    >> of cumbersome when all you want to do is find the equivalents to
    >> e.g. 'a'. Would it make sense to have something similar to
    >> `read-char-by-name' but that accepted single characters *without*
    >> treating those as hex? Youʼd still be able to enter single digit
    >> hex characters by prefixing them with '0'.

    Juri> Wouldn't it be cleaner to use just (read-char-from-minibuffer "Character: ")
    Juri> where you can either type a character directly or use 'C-x 8 RET'
    Juri> to insert a character by its name.

I guess that works as well, but then youʼre assuming knowledge of 'C-x
8 RETʼ. I canʼt come up with a strong argument either ways, so Iʼm
going to chicken out here and see what Eli says ☺️

Robert
-- 

Re: emacs-28 a866674b2a: Fix inaccuracies in "lax search" documentation

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Wed, 31 Aug 2022 18:36:23 +0200
> 
> >>>>> On Wed, 31 Aug 2022 19:09:34 +0300, Juri Linkov <juri@linkov.net> said:
> 
>     >> I have one comment: using `read-char-by-name' is kind
>     >> of cumbersome when all you want to do is find the equivalents to
>     >> e.g. 'a'. Would it make sense to have something similar to
>     >> `read-char-by-name' but that accepted single characters *without*
>     >> treating those as hex? Youʼd still be able to enter single digit
>     >> hex characters by prefixing them with '0'.
> 
>     Juri> Wouldn't it be cleaner to use just (read-char-from-minibuffer "Character: ")
>     Juri> where you can either type a character directly or use 'C-x 8 RET'
>     Juri> to insert a character by its name.
> 
> I guess that works as well, but then youʼre assuming knowledge of 'C-x
> 8 RETʼ. I canʼt come up with a strong argument either ways, so Iʼm
> going to chicken out here and see what Eli says ☺️

Eli says that he was mightily surprised to see that just typing a
character at the prompt didn't take that character literally, but
instead interpreted it as a hex codepoint.

Re: emacs-28 a866674b2a: Fix inaccuracies in "lax search" documentation

[Robert Pluim]

>>>>> On Wed, 31 Aug 2022 19:40:10 +0300, Eli Zaretskii <eliz@gnu.org> said:

    Juri> Wouldn't it be cleaner to use just (read-char-from-minibuffer "Character: ")
    Juri> where you can either type a character directly or use 'C-x 8 RET'
    Juri> to insert a character by its name.
    >> 
    >> I guess that works as well, but then youʼre assuming knowledge of 'C-x
    >> 8 RETʼ. I canʼt come up with a strong argument either ways, so Iʼm
    >> going to chicken out here and see what Eli says ☺️

    Eli> Eli says that he was mightily surprised to see that just typing a
    Eli> character at the prompt didn't take that character literally, but
    Eli> instead interpreted it as a hex codepoint.

That pleads for `read-char-from-minibuffer', except that

(read-char-from-minibuffer "Character: ") RET
C-x 8 RET
LATIN SMALL LETTER A WITH DIAERESIS
=> [Wrong Answer]

which pleads for extending `read-char-by-name' to not do that single
character hex thing.

Robert
-- 

Re: emacs-28 a866674b2a: Fix inaccuracies in "lax search" documentation

[Juri Linkov]

>     Juri> Wouldn't it be cleaner to use just (read-char-from-minibuffer "Character: ")
>     Juri> where you can either type a character directly or use 'C-x 8 RET'
>     Juri> to insert a character by its name.
>     >> 
>     >> I guess that works as well, but then youʼre assuming knowledge of 'C-x
>     >> 8 RETʼ. I canʼt come up with a strong argument either ways, so Iʼm
>     >> going to chicken out here and see what Eli says ☺️
>
>     Eli> Eli says that he was mightily surprised to see that just typing a
>     Eli> character at the prompt didn't take that character literally, but
>     Eli> instead interpreted it as a hex codepoint.
>
> That pleads for `read-char-from-minibuffer', except that
>
> (read-char-from-minibuffer "Character: ") RET
> C-x 8 RET
> LATIN SMALL LETTER A WITH DIAERESIS
> => [Wrong Answer]
>
> which pleads for extending `read-char-by-name' to not do that single
> character hex thing.

I see it the other way around - that pleads for fixing
`read-char-from-minibuffer':

```
diff --git a/lisp/subr.el b/lisp/subr.el
index 2ffc594997..71fb9f3875 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -3327,7 +3327,6 @@ read-char-from-minibuffer-map
     (set-keymap-parent map minibuffer-local-map)
 
     (define-key map [remap self-insert-command] #'read-char-from-minibuffer-insert-char)
-    (define-key map [remap exit-minibuffer] #'read-char-from-minibuffer-insert-other)
 
     (define-key map [remap recenter-top-bottom] #'minibuffer-recenter-top-bottom)
     (define-key map [remap scroll-up-command] #'minibuffer-scroll-up-command)
```

Then

  (read-char-from-minibuffer "Character: ") RET
  C-x 8 RET LATIN SMALL LETTER A WITH DIAERESIS RET
  RET

Re: emacs-28 a866674b2a: Fix inaccuracies in "lax search" documentation

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Wed, 31 Aug 2022 20:13:45 +0300
> 
> I see it the other way around - that pleads for fixing
> `read-char-from-minibuffer':

You do?

If read-char-from-minibuffer is supposed to return a single character,
it cannot return nil (or anything else that indicates empty input).
If you make such a change, expect it to break many use cases
elsewhere.

To me, the above says that read-char-from-minibuffer is not the right
tool for this job.

Re: emacs-28 a866674b2a: Fix inaccuracies in "lax search" documentation

[Robert Pluim]

>>>>> On Wed, 31 Aug 2022 20:22:30 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Juri Linkov <juri@linkov.net>
    >> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
    >> Date: Wed, 31 Aug 2022 20:13:45 +0300
    >> 
    >> I see it the other way around - that pleads for fixing
    >> `read-char-from-minibuffer':

    Eli> You do?

    Eli> If read-char-from-minibuffer is supposed to return a single character,
    Eli> it cannot return nil (or anything else that indicates empty input).
    Eli> If you make such a change, expect it to break many use cases
    Eli> elsewhere.

    Eli> To me, the above says that read-char-from-minibuffer is not the right
    Eli> tool for this job.

Hereʼs the kind of thing I had in mind:

diff --git a/lisp/international/mule-cmds.el b/lisp/international/mule-cmds.el
index 12896cc4b0..4137642528 100644
--- a/lisp/international/mule-cmds.el
+++ b/lisp/international/mule-cmds.el
@@ -3195,7 +3195,7 @@ read-char-by-name-sort
   :group 'mule
   :version "28.1")
 
-(defun read-char-by-name (prompt)
+(defun read-char-by-name (prompt &optional allow-single)
   "Read a character by its Unicode name or hex number string.
 Display PROMPT and read a string that represents a character by its
 Unicode property `name' or `old-name'.
@@ -3216,7 +3216,10 @@ read-char-by-name
 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."
+as names, not numbers.
+
+Optional arg ALLOW-SINGLE non-nil means to additionally allow
+single characters to be treated as standing for themselves."
   (let* ((enable-recursive-minibuffers t)
 	 (completion-ignore-case t)
 	 (completion-tab-width 4)
@@ -3239,6 +3242,9 @@ read-char-by-name
 	 (char
           (cond
            ((char-from-name input t))
+           ((and allow-single
+                 (string-match-p "\\`.\\'" input)
+                 (ignore-errors (string-to-char input))))
            ((string-match-p "\\`[[:xdigit:]]+\\'" input)
             (ignore-errors (string-to-number input 16)))
            ((string-match-p "\\`#\\([bBoOxX]\\|[0-9]+[rR]\\)[0-9a-zA-Z]+\\'"

Robert
-- 

RE: [External] : Re: emacs-28 a866674b2a: Fix inaccuracies in "lax search" documentation

[Drew Adams]

> If read-char-from-minibuffer is supposed to return a single character,
> it cannot return nil (or anything else that indicates empty input).
> If you make such a change, expect it to break many use cases
> elsewhere.
>
> To me, the above says that read-char-from-minibuffer is not the right
> tool for this job.

+1.

(IMO it's not the right tool for very many jobs, if any.)

Re: emacs-28 a866674b2a: Fix inaccuracies in "lax search" documentation

[Juri Linkov]

> If read-char-from-minibuffer is supposed to return a single character,
> it cannot return nil (or anything else that indicates empty input).
> If you make such a change, expect it to break many use cases
> elsewhere.

This was meant to return a single character by typing RET when
a single character was already inserted to the minibuffer before.
I.e. a new command bound to RET that should exit with a single
character from the minibuffer.  If this is a good idea.

Re: emacs-28 a866674b2a: Fix inaccuracies in "lax search" documentation

[Stefan Monnier]

>> I have one comment: using `read-char-by-name' is kind
>> of cumbersome when all you want to do is find the equivalents to
>> e.g. 'a'. Would it make sense to have something similar to
>> `read-char-by-name' but that accepted single characters *without*
>> treating those as hex? Youʼd still be able to enter single digit
>> hex characters by prefixing them with '0'.
> Wouldn't it be cleaner to use just (read-char-from-minibuffer "Character: ")
> where you can either type a character directly or use 'C-x 8 RET'
> to insert a character by its name.

I lost the beginning of this discussion: why can't we unify
`read-char-from-minibuffer` and `read-char-by-name' into a single function?


        Stefan

Re: emacs-28 a866674b2a: Fix inaccuracies in "lax search" documentation

[Juri Linkov]

>>> I have one comment: using `read-char-by-name' is kind
>>> of cumbersome when all you want to do is find the equivalents to
>>> e.g. 'a'. Would it make sense to have something similar to
>>> `read-char-by-name' but that accepted single characters *without*
>>> treating those as hex? Youʼd still be able to enter single digit
>>> hex characters by prefixing them with '0'.
>> Wouldn't it be cleaner to use just (read-char-from-minibuffer "Character: ")
>> where you can either type a character directly or use 'C-x 8 RET'
>> to insert a character by its name.
>
> I lost the beginning of this discussion: why can't we unify
> `read-char-from-minibuffer` and `read-char-by-name' into a single function?

Robert sent a patch that does this by adding a new arg ALLOW-SINGLE
to `read-char-by-name'.

Re: emacs-28 a866674b2a: Fix inaccuracies in "lax search" documentation

[Robert Pluim]

>>>>> On Thu, 01 Sep 2022 10:22:55 +0300, Juri Linkov <juri@linkov.net> said:

    >>>> I have one comment: using `read-char-by-name' is kind
    >>>> of cumbersome when all you want to do is find the equivalents to
    >>>> e.g. 'a'. Would it make sense to have something similar to
    >>>> `read-char-by-name' but that accepted single characters *without*
    >>>> treating those as hex? Youʼd still be able to enter single digit
    >>>> hex characters by prefixing them with '0'.
    >>> Wouldn't it be cleaner to use just (read-char-from-minibuffer "Character: ")
    >>> where you can either type a character directly or use 'C-x 8 RET'
    >>> to insert a character by its name.
    >> 
    >> I lost the beginning of this discussion: why can't we unify
    >> `read-char-from-minibuffer` and `read-char-by-name' into a single function?

    Juri> Robert sent a patch that does this by adding a new arg ALLOW-SINGLE
    Juri> to `read-char-by-name'.

You still need to hit RET though, unlike `read-char-from-minibuffer'.

Robert
-- 

Re: emacs-28 a866674b2a: Fix inaccuracies in "lax search" documentation

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  Eli Zaretskii
>  <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Thu, 01 Sep 2022 10:14:55 +0200
> 
> >>>>> On Thu, 01 Sep 2022 10:22:55 +0300, Juri Linkov <juri@linkov.net> said:
> 
>     >> I lost the beginning of this discussion: why can't we unify
>     >> `read-char-from-minibuffer` and `read-char-by-name' into a single function?
> 
>     Juri> Robert sent a patch that does this by adding a new arg ALLOW-SINGLE
>     Juri> to `read-char-by-name'.
> 
> You still need to hit RET though, unlike `read-char-from-minibuffer'.

I don't see how we could avoid that as long as we also want to support
specifying a character by its Unicode name or codepoint.

Re: emacs-28 a866674b2a: Fix inaccuracies in "lax search" documentation

[Robert Pluim]

>>>>> On Thu, 01 Sep 2022 14:34:51 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  Eli Zaretskii
    >> <eliz@gnu.org>,  emacs-devel@gnu.org
    >> Date: Thu, 01 Sep 2022 10:14:55 +0200
    >> 
    >> >>>>> On Thu, 01 Sep 2022 10:22:55 +0300, Juri Linkov <juri@linkov.net> said:
    >> 
    >> >> I lost the beginning of this discussion: why can't we unify
    >> >> `read-char-from-minibuffer` and `read-char-by-name' into a single function?
    >> 
    Juri> Robert sent a patch that does this by adding a new arg ALLOW-SINGLE
    Juri> to `read-char-by-name'.
    >> 
    >> You still need to hit RET though, unlike `read-char-from-minibuffer'.

    Eli> I don't see how we could avoid that as long as we also want to support
    Eli> specifying a character by its Unicode name or codepoint.

We canʼt, but it also means we canʼt use it to replace
`read-char-from-minibuffer' like Stefan wanted.

Robert
-- 

Re: emacs-28 a866674b2a: Fix inaccuracies in "lax search" documentation

[Stefan Monnier]

>     >> >> I lost the beginning of this discussion: why can't we unify
>     >> >> `read-char-from-minibuffer` and `read-char-by-name' into a single function?
>     >> 
>     Juri> Robert sent a patch that does this by adding a new arg ALLOW-SINGLE
>     Juri> to `read-char-by-name'.
>     >> 
>     >> You still need to hit RET though, unlike `read-char-from-minibuffer'.

Oh, right `read-char-from-minibuffer` is more like `read-key` and is not
a good choice (IMO) to let the user enter "any char" (many chars would
require the use of an input method and it doesn't seem easy to make
that work).

Then I'm all for `allow-single`.


        Stefan

Re: emacs-28 a866674b2a: Fix inaccuracies in "lax search" documentation

[Robert Pluim]

>>>>> On Thu, 01 Sep 2022 09:00:30 -0400, Stefan Monnier <monnier@iro.umontreal.ca> said:

    >> >> >> I lost the beginning of this discussion: why can't we unify
    >> >> >> `read-char-from-minibuffer` and `read-char-by-name' into a single function?
    >> >> 
    Juri> Robert sent a patch that does this by adding a new arg ALLOW-SINGLE
    Juri> to `read-char-by-name'.
    >> >> 
    >> >> You still need to hit RET though, unlike `read-char-from-minibuffer'.

    Stefan> Oh, right `read-char-from-minibuffer` is more like `read-key` and is not
    Stefan> a good choice (IMO) to let the user enter "any char" (many chars would
    Stefan> require the use of an input method and it doesn't seem easy to make
    Stefan> that work).

Oh, we can make it seem to work easily enough, Iʼm just scared of the
fallout 😀

    Stefan> Then I'm all for `allow-single`.

OK. Iʼll work on the documentation.

Robert
-- 

Re: emacs-28 a866674b2a: Fix inaccuracies in "lax search" documentation

[Robert Pluim]

>>>>> On Thu, 01 Sep 2022 15:07:26 +0200, Robert Pluim <rpluim@gmail.com> said:

    Robert> OK. Iʼll work on the documentation.

Hm,, `read-char-by-name' is not in the elisp reference manual at
all. How about I put it in the "Text from Minibuffer" node, just after
`read-string-from-buffer'?

Robert
-- 

Re: emacs-28 a866674b2a: Fix inaccuracies in "lax search" documentation

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  juri@linkov.net,  emacs-devel@gnu.org
> Date: Thu, 01 Sep 2022 17:28:24 +0200
> 
> >>>>> On Thu, 01 Sep 2022 15:07:26 +0200, Robert Pluim <rpluim@gmail.com> said:
> 
>     Robert> OK. Iʼll work on the documentation.
> 
> Hm,, `read-char-by-name' is not in the elisp reference manual at
> all. How about I put it in the "Text from Minibuffer" node, just after
> `read-string-from-buffer'?

We don't need to have it in the manual, unless it is an important and
popular API.  Is it?

Re: emacs-28 a866674b2a: Fix inaccuracies in "lax search" documentation

[Robert Pluim]

>>>>> On Thu, 01 Sep 2022 18:30:34 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Cc: Eli Zaretskii <eliz@gnu.org>,  juri@linkov.net,  emacs-devel@gnu.org
    >> Date: Thu, 01 Sep 2022 17:28:24 +0200
    >> 
    >> >>>>> On Thu, 01 Sep 2022 15:07:26 +0200, Robert Pluim <rpluim@gmail.com> said:
    >> 
    Robert> OK. Iʼll work on the documentation.
    >> 
    >> Hm,, `read-char-by-name' is not in the elisp reference manual at
    >> all. How about I put it in the "Text from Minibuffer" node, just after
    >> `read-string-from-buffer'?

    Eli> We don't need to have it in the manual, unless it is an important and
    Eli> popular API.  Is it?

Itʼs only got 3 callers in-tree, so not that popular. And it already
has a very complete docstring 😀

Robert
--