bug#36454: 26.2.90; feature request - Insert char by hex tab completion or C-x 8 RET ffe <TAB>

bug#36454: 26.2.90; feature request - Insert char by hex tab completion or C-x 8 RET ffe <TAB>

[Drew Adams]

> > No, you won't get lots of results.  There's little overlap
> > in general, even if you type only a few chars.  Certainly
> > less than you get with function and variable names,
> > especially those that have common prefixes.
> >
> > You'll typically type little to get to a single candidate.
> 
> Try "ff" or "fe" for some perspective.

With Emacs 23:

For "ff" there are 29 matching char names and
438 matching code points, total: 467.  Zero
overlap.

If you really want to be extreme, try just "f"
(see below).

Obviously you can ask to complete input that
results in many candidates.  That's true even
with just names as candidates.  Don't do that,
if you don't want lots of candidates.

IMO, the main advantage in completing code
points is not to save typing to enter a char.
It's to see the char names in `*Completions*'.
Completing 1 or 2 hex chars, just to save
typing 3 or 2 more, is not the point.  It's
about seeing what names match.

If you just want to insert a char by giving
its code point, it's not hard to type 4 hex
chars.  Completion is not really gaining you
anything for that goal. 

In general, it's a small percentage of char
names that include hex-char sequences, and
the longer the sequence the quicker that
percentage shrinks.  There are exceptions,
of course.

Let's see:

There are 5452 matches for input "9".
Of those, 132 are matches for a char name
(2% overlap).

Add an "a", to check "9a".  The 5454 drops
to 230, and the 132 drops to 8 (3% overlap).

For "9f" it's 203 total, only 1 name match
(0.4% overlap).

With regexp "9a\|a9" you can check for
matching either "9a" or "a9", which gives
626 total and 9 name-only (1% overlap).

For:

  "f": 10,113 total, 5,539 matching names (54% overlap)
 "fa":    353 total, 121 matching names   (34% overlap)
 "ee":  1,921 total, 1713 matching names  (89% overlap)
 "aa":    792 total, 417 matching names   (53% overlap)

"aaa":     21 total, 0 matching names      (no overlap)
"123":    174 total, 33 matching names    (19% overlap)
"321":     58 total, 0 matching names      (no overlap)
 "99":    221 total, 1 matching name     (0.4% overlap)
 "bc":    440 total, 2 matching names    (0.4% overlap)

But yes, if you want to see _only_ code-point
matches, and you want to type _only_ "f", say,
then this might not be for you.  If you think
this would be a problem for many people (I
don't), you could make it an option, of course.

And if you're not interested in such a feature,
fine.  Just wanted to share my (long) experience
with it, and suggest that it's easy to use and
quite useful.  You're not obliged to agree.  No
obligation to appreciate substring completion
for `C-x 8 RET' either.

bug#36454: 26.2.90; feature request - Insert char by hex tab completion or C-x 8 RET ffe <TAB>

[Eli Zaretskii]

> Date: Thu, 18 Jul 2019 16:15:23 +0000 (UTC)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: mrsebastianurban@gmail.com, larsi@gnus.org, van@scratch.space,
>         36454@debbugs.gnu.org
> 
> > > No, you won't get lots of results.  There's little overlap
> > > in general, even if you type only a few chars.  Certainly
> > > less than you get with function and variable names,
> > > especially those that have common prefixes.
> > >
> > > You'll typically type little to get to a single candidate.
> > 
> > Try "ff" or "fe" for some perspective.
> [...]
> If you really want to be extreme, try just "f"

You are missing the point.  My point is that your example is somewhat
skewed: Unicode codepoints in hex go from 0 to 1fffff, so the number
of possible matches for the initial "ffe" is quite small, to put it
mildly.  Real-life examples might yield one or even two orders of
magnitude more candidates; e.g. "fe" as substring (not just the
leading substring) will gives you more than 500.  Even replacing "ffe"
with "123" will already give 170 just of those that begin with "123".
I hope we agree that wading through 170 completion candidates, let
alone 500, is not very convenient, yes?

Bottom line: IME completing on digits is rarely useful, unless you
assume that the user will type almost all of the digits, leaving just
one or two for completion.  And how probable is it that the user will
know the codepoint up to 1 or 2 last digits, but will not know the
entire codepoint?

bug#36454: 26.2.90; feature request - Insert char by hex tab completion or C-x 8 RET ffe <TAB>

[Drew Adams]

> > what about (additional) variable which would control
> > completion style in this case, with values:
> > - name - default, completion in 'insert-char' would work like it
> >    works now,
> > - name-and-hex - completion in 'insert-char' would also complete hex
> >    codes and show everything in *Completions* window,
> >
> > or just t/nil instead of name/name-and-hex.
> 
> Could be OK.

Just what I said earlier:

  But yes, if you want to see _only_ code-point
  matches, and you want to type _only_ "f", say,
  then this might not be for you.  If you think
  this would be a problem for many people (I
  don't), you could make it an option, of course.
                    ^^^^^^^^^^^^^^^^^

bug#36454: 26.2.90; feature request - Insert char by hex tab completion or C-x 8 RET ffe <TAB>

[Drew Adams]

> Since this feature is proposed for core Emacs, we are by definition
> talking about "emacs -Q", not about Ivy or Helm.  The latter have
> infrastructure on which to build the feature you want without any
> changes in core.

Core Emacs could have such behavior.

It's not about what I want for my own use (I use
Icicles, which provides all of that and more).

We're discussing what vanilla Emacs could do.
This bug thread is a "feature request", and one
specifically to "insert char by hex tab completion...".

> > > it can be used for that, but with very low efficiency and user-
> friendliness.
> >
> > That's too big a generalization to be helpful in this
> > discussion.
> 
> Generalizations are sometimes useful tools for making decisions and
> getting one's point across.

Another generalization not helpful in this context.
Even a platitude, with which few would disagree.

If you really want to make the point that completion
implies "very low efficiency and user-friendliness",
and you think that belongs in this discussion then I
suggest some evidence and specifics would help your
argument.

As only an opinion stated in such general terms I
don't find it useful in the present context; sorry.

> > > So we should not judge the need for completion by considering any
> > > use cases other than just completion, i.e. finding a specific character
> > > or a small group of related characters.
> >
> > Need?  How about value and usefulness?
> 
> Indeed, I think it would be useless, even harmful.

A good place to end.

bug#36454: 26.2.90; feature request - Insert char by hex tab completion or C-x 8 RET ffe <TAB>

[Sebastian Urban]

> A good place to end.

Before that, what about (additional) variable which would control
completion style in this case, with values:
- name - default, completion in 'insert-char' would work like it works
   now,
- name-and-hex - completion in 'insert-char' would also complete hex
   codes and show everything in *Completions* window,

or just t/nil instead of name/name-and-hex.

bug#36454: 26.2.90; feature request - Insert char by hex tab completion or C-x 8 RET ffe <TAB>

[Eli Zaretskii]

> From: Sebastian Urban <mrsebastianurban@gmail.com>
> Cc: larsi@gnus.org, van@scratch.space, 36454@debbugs.gnu.org
> Date: Fri, 19 Jul 2019 22:12:03 +0200
> 
> what about (additional) variable which would control
> completion style in this case, with values:
> - name - default, completion in 'insert-char' would work like it works
>    now,
> - name-and-hex - completion in 'insert-char' would also complete hex
>    codes and show everything in *Completions* window,
> 
> or just t/nil instead of name/name-and-hex.

Could be OK.

bug#36454: 26.2.90; feature request - Insert char by hex tab completion or C-x 8 RET ffe <TAB>

[Lars Ingebrigtsen]

Sebastian Urban <mrsebastianurban@gmail.com> writes:

> Before that, what about (additional) variable which would control
> completion style in this case, with values:
> - name - default, completion in 'insert-char' would work like it works
>   now,
> - name-and-hex - completion in 'insert-char' would also complete hex
>   codes and show everything in *Completions* window,

I don't think completing over hex codes is a good idea (it's a very
dehumanising interface), and I don't think adding a variable to switch
it off or on is, either.

But what you really want is (it seems to me) to be able to list all
characters from a Unicode block, because you know where the character
is, but you want to find a specific one in that neighbourhood.  So the
"hex completion" is just an artefact here.  Instead, perhaps there
should be a new command to complete over Unicode block names, and then
list the characters in that block, and allow you to choose one of them?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#36454: 26.2.90; feature request - Insert char by hex tab completion or C-x 8 RET ffe <TAB>

[Sebastian Urban]

> I don't think completing over hex codes is a good idea (it's a very
> dehumanising interface), and I don't think adding a variable to
> switch it off or on is, either.

Well, this is why it would be optional, an extension of the default
behaviour, only for those who want it.  At least until someone will do
bigger makeover.

> But what you really want is (it seems to me) to be able to list all
> characters from a Unicode block, because you know where the
> character is, but you want to find a specific one in that
> neighbourhood.

Hmmm... this sounds kind of like (on emacs 26.2):
'M-x list-charset-chars RET unicode-bmp/sip/smp/ssp RET'.
Assuming someone knows hex code or part of it, simply doing
'isearch-forward' will bring him to the neighbourhood of the character
he is looking for.

> Instead, perhaps there should be a new command to complete over
> Unicode block names, and then list the characters in that block, and
> allow you to choose one of them?

This sounds more like bigger(?) upgrade of 'insert-char', rather than
a new command.

bug#36454: 26.2.90; feature request - Insert char by hex tab completion or C-x 8 RET ffe <TAB>

[Eli Zaretskii]

> From: Sebastian Urban <mrsebastianurban@gmail.com>
> Cc: Drew Adams <drew.adams@oracle.com>, Eli Zaretskii <eliz@gnu.org>,
>  van@scratch.space, 36454@debbugs.gnu.org
> Date: Sat, 20 Jul 2019 16:36:20 +0200
> 
> > But what you really want is (it seems to me) to be able to list all
> > characters from a Unicode block, because you know where the
> > character is, but you want to find a specific one in that
> > neighbourhood.
> 
> Hmmm... this sounds kind of like (on emacs 26.2):
> 'M-x list-charset-chars RET unicode-bmp/sip/smp/ssp RET'.

list-charset-chars doesn't have the Unicode block granularity, it is
much coarser.

bug#36454: 26.2.90; feature request - Insert char by hex tab completion or C-x 8 RET ffe <TAB>

[Drew Adams]

> > > I hope we agree that wading through 170 completion candidates, let
> > > alone 500, is not very convenient, yes?
> >
> > No, we don't agree that 500 completion candidates
> > is a problem.
> 
> I'm surprised to hear that, but maybe I shouldn't.

It's not a problem if you can easily filter to narrow
the choices.  That's the key.  Seeing that there are
initially 500 matches, and seeing the kinds of matches
they are, gives you an interactive, quick, incremental
idea how you might want to further narrow the field.

But certainly, if you do NOT have a good, quick,
powerful way to narrow further then yes, 500 candidates
is unwieldy.  Even UIs that offer cycling among
candidates are inefficient and nearly useless in such
a situation, IF they don't also allow for progressive
narrowing.

> > Completion is not just an aid for entering input.
> > It's a way to discover, browse, search, etc. a
> > set of information.
> 
> Completion is a very poor means for discovery and browsing.

1. Even if that were true, it is not by itself an
   argument against improving completion, including
   for discovery and browsing.

2. I disagree that it is true.  I would suggest/guess
   that you just don't have sufficient experience with
   a better completion UI than that offered by `emacs -Q'.
   Ask users of Ivy or Helm whether they use completion
   that way.

> If we want tools for discovering characters, we should have more powerful
> commands:

Nothing prevents _both_ better completion and other tools
for char (and other) discovery.  It's not either-or,
logically.  It may be either-or in terms of commitment of
resources to implement such choices.

No tool is the best tool for everything.  And I don't
know anyone who would just reply " completion is the
answer" to every problem.

> list characters by their Unicode block, by their script, by
> their attributes, etc.

Couldn't agree more about the utility of such aids.
(Contributions are welcome, as some like to say.)

> Completion is not for all of that;

Completion is not the best tool for everything.  Correct.

On the other hand, it's likely that any such additional
tools you might add could themselves also benefit from
better completion.

Ask an Ivy or Helm user whether and how completion
improves all kinds of existing Emacs commands, including
help and other information-provider commands such as
apropos and Info. 

> it can be used for that, but with very low efficiency and user-friendliness.

That's too big a generalization to be helpful in this
discussion.

> So we should not judge the need for completion by considering any use
> cases other than just completion, i.e. finding a specific character or
> a small group of related characters.

Need?  How about value and usefulness?

bug#36454: 26.2.90; feature request - Insert char by hex tab completion or C-x 8 RET ffe <TAB>

[Eli Zaretskii]

> Date: Fri, 19 Jul 2019 14:38:40 +0000 (UTC)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: mrsebastianurban@gmail.com, larsi@gnus.org, van@scratch.space,
>         36454@debbugs.gnu.org
> 
> > Completion is a very poor means for discovery and browsing.
> [...]
> 2. I disagree that it is true.  I would suggest/guess
>    that you just don't have sufficient experience with
>    a better completion UI than that offered by `emacs -Q'.
>    Ask users of Ivy or Helm whether they use completion
>    that way.

Since this feature is proposed for core Emacs, we are by definition
talking about "emacs -Q", not about Ivy or Helm.  The latter have
infrastructure on which to build the feature you want without any
changes in core.

> > it can be used for that, but with very low efficiency and user-friendliness.
> 
> That's too big a generalization to be helpful in this
> discussion.

Generalizations are sometimes useful tools for making decisions and
getting one's point across.

> > So we should not judge the need for completion by considering any use
> > cases other than just completion, i.e. finding a specific character or
> > a small group of related characters.
> 
> Need?  How about value and usefulness?

Indeed, I think it would be useless, even harmful.

bug#36454: 26.2.90; feature request - Insert char by hex tab completion or C-x 8 RET ffe <TAB>

[Drew Adams]

> I hope we agree that wading through 170 completion candidates, let
> alone 500, is not very convenient, yes?

No, we don't agree that 500 completion candidates
is a problem.  Of course, it depends on whether
you have a completion UI that lets you easily
narrow that in useful ways. If you don't then
it's less useful/convenient.

> Bottom line: IME completing on digits is rarely useful, unless you
> assume that the user will type almost all of the digits, leaving just
> one or two for completion.  And how probable is it that the user will
> know the codepoint up to 1 or 2 last digits, but will not know the
> entire codepoint?

That repeats what I said (so there is at least
one thing that we perhaps agree about):

  IMO, the main advantage in completing code
  points is not to save typing to enter a char.
  It's to see the char names in `*Completions*'.
  Completing 1 or 2 hex chars, just to save
  typing 3 or 2 more, is not the point.  It's
  about seeing what names match.

  If you just want to insert a char by giving
  its code point, it's not hard to type 4 hex
  chars.  Completion is not really gaining you
  anything for that goal.

Completion is not just an aid for entering input.
It's a way to discover, browse, search, etc. a
set of information.

This is also why we show the char itself and the
code point.  Being able to type text to _match_
any of those bits of info, or any combination of
them, gives you a way to see not only code points
that correspond to names but names that correspond
to code points.  Likewise, names and code points
that correspond to chars themselves.

We're currently showing, in effect, a table of
such correspondences in `*Completions*', but you
can only narrow the table entries by filtering
on names.  It's also useful to be able to filter
on code points.  It's even useful to be able to
type a char and see its name and code point.

bug#36454: 26.2.90; feature request - Insert char by hex tab completion or C-x 8 RET ffe <TAB>

[Eli Zaretskii]

> Date: Thu, 18 Jul 2019 20:44:46 +0000 (UTC)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: mrsebastianurban@gmail.com, larsi@gnus.org, van@scratch.space,
>         36454@debbugs.gnu.org
> 
> > I hope we agree that wading through 170 completion candidates, let
> > alone 500, is not very convenient, yes?
> 
> No, we don't agree that 500 completion candidates
> is a problem.

I'm surprised to hear that, but maybe I shouldn't.

> Completion is not just an aid for entering input.
> It's a way to discover, browse, search, etc. a
> set of information.

Completion is a very poor means for discovery and browsing.  If we
want tools for discovering characters, we should have more powerful
commands: list characters by their Unicode block, by their script, by
their attributes, etc.  Completion is not for all of that; it can be
used for that, but with very low efficiency and user-friendliness.  So
we should not judge the need for completion by considering any use
cases other than just completion, i.e. finding a specific character or
a small group of related characters.

bug#36454: 26.2.90; feature request - Insert char by hex tab completion or C-x 8 RET ffe <TAB>

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Completion is a very poor means for discovery and browsing.

There could be better, but I have used completion with C-x 8 RET
in the past few weeks to discover characters.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#36454: 26.2.90; feature request - Insert char by hex tab completion or C-x 8 RET ffe <TAB>

[VanL]

> On 20 Jul 2019, at 09:07, Richard Stallman <rms@gnu.org> wrote:
> 
>> Completion is a very poor means for discovery and browsing.
> 
> There could be better, but I have used completion with C-x 8 RET
> in the past few weeks to discover characters.

That was how I used to find characters before purely by chance I found

  https://unicode.org/charts/

and, there, it is possible to see 'ffea' in context with its nearest neighbors in UFF00.pdf.  For TAB completion on 'ffe' I was wanting the a..c range and expected the widest extraction to include the 0..f range for 16 completions.

bug#36454: 26.2.90; feature request - Insert char by hex tab completion or C-x 8 RET ffe <TAB>

[VanL]

Hello Emacs,

This is a feature request for 'Insert character (Unicode name or hex)'
to include 'hex tab completion'.  For example, to use one of the ffe
common prefix arrow symbols from unicode.

Type:
-input-  C-x 8 RET
-output- Insert character (Unicode name or hex):
-input-  ffe <TAB>

Expect Emacs's response to include hex tab completions for 'ffe <TAB>'

  ￩ ffe9
  ￪ ffea
  ￫ ffeb
  ￬ ffec

But, Emacs's response only has Unicode name completion, like GIRAFFE FACE.

-output- Making completion list...
-- quote
   Click on a completion to select it.
   In this buffer, type RET to select the completion near point.
   
   Possible completions are:
   DIFFERENCE BETWEEN (≏) 	GIRAFFE FACE (🦒)
   MATHEMATICAL BOLD ITALIC PARTIAL DIFFERENTIAL (𝝏)
   MATHEMATICAL BOLD PARTIAL DIFFERENTIAL (𝛛)
   MATHEMATICAL ITALIC PARTIAL DIFFERENTIAL (𝜕)
   MATHEMATICAL SANS-SERIF BOLD ITALIC PARTIAL DIFFERENTIAL (𝟃)
   MATHEMATICAL SANS-SERIF BOLD PARTIAL DIFFERENTIAL (𝞉)
   PARTIAL DIFFERENTIAL (∂) 	SIGNWRITING CHEEKS PUFFED (𝨪)
   STUFFED FLATBREAD (🥙)
-- quote ends --

bug#36454: 26.2.90; feature request - Insert char by hex tab completion or C-x 8 RET ffe <TAB>

[Lars Ingebrigtsen]

VanL <van@scratch.space> writes:

> This is a feature request for 'Insert character (Unicode name or hex)'
> to include 'hex tab completion'.  For example, to use one of the ffe
> common prefix arrow symbols from unicode.
>
> Type:
> -input-  C-x 8 RET
> -output- Insert character (Unicode name or hex):
> -input-  ffe <TAB>
>
> Expect Emacs's response to include hex tab completions for 'ffe <TAB>'
>
>   ￩ ffe9
>   ￪ ffea
>   ￫ ffeb
>   ￬ ffec
>
> But, Emacs's response only has Unicode name completion, like GIRAFFE FACE.

Hm...  I don't think this sounds very useful, because the hex values are
kinda tightly packed, so you get too many matches.  And they get in the
way of name completion.  So I'm closing this as a wontfix; if somebody
disagrees, feel free to reopen.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#36454: 26.2.90; feature request - Insert char by hex tab completion or C-x 8 RET ffe <TAB>

[Sebastian Urban]

Not that I disagree, but I have this idea.  There are 3 ways of
specifying character for 'C-x 8 RET':
1. Unicode name,
2. hex code,
3. code with radix specified, e.g. #o... (octal), #x... (hex),
    #10r...(decimal).

While it'll be difficult(?) to have both completions for name and hex
code (point 1. and 2.), because for example some names include
numbers, completions based on the code for 3rd method of inserting
char could be added.  This way if someone type letters or numbers -
method 1. or 2. - he'll get completions based on Unicode name.  BUT if
he define radix in the beginning (#b/#o/#x/#RADIXr), possible
completions based on the code will appear.  A bit more typing
(defining radix) but it could work.  This way we could also get
completions for other codes than hex.

> I don't think this sounds very useful, because the hex values are
> kinda tightly packed, so you get too many matches.

With approach described above, it'll only happen with 3rd method -
probably not the most popular.  Also I think if someone will try to
complete it, he'll do it after typing at least 2 or as OP - 3 letters.

> And they get in the way of name completion.

With approach described above, this problem doesn't exist.

bug#36454: 26.2.90; feature request - Insert char by hex tab completion or C-x 8 RET ffe <TAB>

[Drew Adams]

> Not that I disagree, but I have this idea.  There are 3 ways of
> specifying character for 'C-x 8 RET':
> 1. Unicode name,
> 2. hex code,
> 3. code with radix specified, e.g. #o... (octal), #x... (hex),
>     #10r...(decimal).
> 
> While it'll be difficult(?) to have both completions for name and hex
> code (point 1. and 2.), because for example some names include
> numbers, completions based on the code for 3rd method of inserting
> char could be added.  This way if someone type letters or numbers -
> method 1. or 2. - he'll get completions based on Unicode name.  BUT if
> he define radix in the beginning (#b/#o/#x/#RADIXr), possible
> completions based on the code will appear.  A bit more typing
> (defining radix) but it could work.  This way we could also get
> completions for other codes than hex.
> 
> > I don't think this sounds very useful, because the hex values are
> > kinda tightly packed, so you get too many matches.
> 
> With approach described above, it'll only happen with 3rd method -
> probably not the most popular.  Also I think if someone will try to
> complete it, he'll do it after typing at least 2 or as OP - 3 letters.
> 
> > And they get in the way of name completion.

There's no problem with allowing completion
against both char names and hex code points.
Haven't seen any problem at all.  (But of
course you'll want to use a substring
completion style.)

---

FWIW - For Emacs 23-25, Icicles supports
your #1 and #2.

[And it supports a 4th kind of completion:
You can enter a Unicode char itself (e.g.
paste it into the minibuffer, or type a
key binding that inserts it), and you see
both its Unicode name and its code point.

IOW, you can use completion to get info
about a char, not just insert a char.]

---

In Emacs 26 they changed to using a hash
table for `ucs-names', which is more
unidirectional than an alist, and I haven't
bothered to try to convert the code.

Maybe I'll fiddle with trying to get
something reasonable using the hash table;
maybe not.

(By "more unidirectional" I mean you can't
easily look up a key, given its value.
I say "more" because maybe you can do it
using `maphash', at quite a cost.  And of
course I could convert the `ucs-names'
hash table to an alist, at high cost.)

bug#36454: 26.2.90; feature request - Insert char by hex tab completion or C-x 8 RET ffe <TAB>

[Sebastian Urban]

> There's no problem with allowing completion against both char names
> and hex code points.

Well I think there may be - how do you distinguish "ffe" as part of
hex code from Unicode name ("GIRAFFE FACE") or "20" as part of hex
code from Unicode name "EGYPTIAN HIEROGLYPH A020"?  With method 1. or
2., i.e. just typing name or hex code, you can't, and only one type of
completion can be made - Unicode name, because it's probably more
reasonable.  And this is why I proposed to make hex (or any other)
code completion available through 3rd method.

On the other hand, while TAB searches through names, maybe just write
"alternative TAB", that will search through hex codes, and bind it to,
for example, 'S-TAB'?

> FWIW - For Emacs 23-25, Icicles supports your #1 and #2.

So this libraries somehow can distinguish "ffe" as part of hex code
from part of Unicode name?

> ... 4th kind of completion: You can enter a Unicode char itself
> (...), and you see both its Unicode name and its code point.

Well, there is 'what-cursor-position' and 'describe-char'... also
I would rather see this behaviour with 'describe-char' in a form of
minibuffer prompt, just like 'describe-face/function/variable', where
you can insert char, type RET, and get the description.

The rest of you message is, I think, outside of my beginner scope of
knowledge, so I'm going to leave it alone.


Again, I just wanted to point a way out from "wontfix" to "maybe" for
this request, by proposing an idea of separating Unicode name
completion from code completion.  The former would be for methods 1st
and 2nd, and the latter would be for 3rd method.

bug#36454: 26.2.90; feature request - Insert char by hex tab completion or C-x 8 RET ffe <TAB>

[Drew Adams]

> > There's no problem with allowing completion against both char names
> > and hex code points.
> 
> Well I think there may be - how do you distinguish "ffe" as part of
> hex code from Unicode name ("GIRAFFE FACE") or "20" as part of hex
> code from Unicode name "EGYPTIAN HIEROGLYPH A020"?  With method 1. or
> 2., i.e. just typing name or hex code, you can't, and only one type of
> completion can be made - Unicode name, because it's probably more
> reasonable.  And this is why I proposed to make hex (or any other)
> code completion available through 3rd method.

You don't need to distinguish them.  You don't
care which part matches "ffe" or "20".  You
don't even care if both name and code point
should happen to match the same pattern.  All
you care about is being able to match the info
about the char: its name or code point.

The completion candidates need to be, _in effect_,
the concatenation of the char name and the code point.

(I wrote: "But of course you'll want to use a
substring completion style.")

bug#36454: 26.2.90; feature request - Insert char by hex tab completion or C-x 8 RET ffe <TAB>

[Sebastian Urban]

> You don't need to distinguish them.  You don't
> care which part matches "ffe" or "20".  You
> don't even care if both name and code point
> should happen to match the same pattern.  All
> you care about is being able to match the info
> about the char: its name or code point.

So, after I type "ffe" and press TAB, it should look through names and
codes at the same time, and present completion candidates for both at
the same time, for example I'll get "￪ ffea" and "GIRAFFE FACE" in the
same window above?

Because, if yes, then user may get a lot of results, as it was pointed
out before.

bug#36454: 26.2.90; feature request - Insert char by hex tab completion or C-x 8 RET ffe <TAB>

[Drew Adams]

> > You don't need to distinguish them.  You don't
> > care which part matches "ffe" or "20".  You
> > don't even care if both name and code point
> > should happen to match the same pattern.  All
> > you care about is being able to match the info
> > about the char: its name or code point.
> 
> So, after I type "ffe" and press TAB, it should look through names and
> codes at the same time, and present completion candidates for both at
> the same time, for example I'll get "￪ ffea" and "GIRAFFE FACE" in the
> same window above?
> 
> Because, if yes, then user may get a lot of results, as it was pointed
> out before.

Have you tried it?

No, you won't get lots of results.  There's little overlap
in general, even if you type only a few chars.  Certainly
less than you get with function and variable names,
especially those that have common prefixes.

You'll typically type little to get to a single candidate.

Completion of `ffe' gives this (using Emacs 23 for this;
no GIRAFFE):
____

DIFFERENCE BETWEEN	224F	≏                               
FULLWIDTH BROKEN BAR	FFE4	￤                              
FULLWIDTH BROKEN VERTICAL BAR	FFE4	￤                      
FULLWIDTH CENT SIGN	FFE0	￠                              
FULLWIDTH MACRON	FFE3	￣                              
FULLWIDTH NOT SIGN	FFE2	￢                              
FULLWIDTH POUND SIGN	FFE1	￡                              
FULLWIDTH SPACING MACRON	FFE3	￣                      
FULLWIDTH WON SIGN	FFE6	￦                              
FULLWIDTH YEN SIGN	FFE5	￥                              
GREEK DASIA	1FFE	῾                                       
HALFWIDTH BLACK SQUARE	FFED	￭                               
HALFWIDTH DOWNWARDS ARROW	FFEC	￬                       
HALFWIDTH FORMS LIGHT VERTICAL	FFE8	￨                       
HALFWIDTH LEFTWARDS ARROW	FFE9	￩                       
HALFWIDTH RIGHTWARDS ARROW	FFEB	￫                       
HALFWIDTH UPWARDS ARROW	FFEA	￪                               
HALFWIDTH WHITE CIRCLE	FFEE	￮                               
HANGUL SYLLABLE BBWEOJ	BFFE	뿾                              
HANGUL SYLLABLE GGWELP	AFFE	꿾                              
HANGUL SYLLABLE KWEOGG	CFFE	쿾                              
MATHEMATICAL BOLD ITALIC PARTIAL DIFFERENTIAL	1D74F	𝝏       
MATHEMATICAL BOLD PARTIAL DIFFERENTIAL	1D6DB	𝛛               
MATHEMATICAL ITALIC PARTIAL DIFFERENTIAL	1D715	𝜕       
MATHEMATICAL SANS-SERIF BOLD ITALIC PARTIAL DIFFERENTIAL	1D7C3	𝟃 
MATHEMATICAL SANS-SERIF BOLD PARTIAL DIFFERENTIAL	1D789	𝞉 
PARTIAL DIFFERENTIAL	2202	∂
____

The overlaps are for 7 char names and 20 code points.

If you were completing _separately_ against only char
names you would still have 7 candidates.  If against
only code points you would still have 20 candidates.
With both together you have 27.

If you typed `iffe' you'd get just 6 (char-name)
candidates.  If you typed `ffea' you'd get just the
char named `HALFWIDTH UPWARDS ARROW'.

[If you typed `[0-9a-f]ffe\|ffe[0-9a-f]' (with
regexp matching) you'd get only the 20 code-point
matches.]

Most char-name chars are not hex chars.  And most
hex-char combinations don't occur in char names.
And those that do occur in both typically don't
occur in many char names.
____

Of course it helps if you can match against multiple
regexps, progressively, as you see the results of
each match, to narrow the set incrementally.  Seeing
the 27 initial matches, typing another (separate)
pattern of, say, `bet' would immediately get you
only candidate `DIFFERENCE BETWEEN	224F	≏'.
____

https://www.emacswiki.org/emacs/Icicles_-_Progressive_Completion

bug#36454: 26.2.90; feature request - Insert char by hex tab completion or C-x 8 RET ffe <TAB>

[Eli Zaretskii]

> Date: Wed, 17 Jul 2019 21:34:36 +0000 (UTC)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 36454@debbugs.gnu.org
> 
> > Because, if yes, then user may get a lot of results, as it was pointed
> > out before.
> 
> Have you tried it?
> 
> No, you won't get lots of results.  There's little overlap
> in general, even if you type only a few chars.  Certainly
> less than you get with function and variable names,
> especially those that have common prefixes.
> 
> You'll typically type little to get to a single candidate.
> 
> Completion of `ffe' gives this (using Emacs 23 for this;
> no GIRAFFE):

Try "ff" or "fe" for some perspective.