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

[Drew Adams <drew.adams@oracle.com>]

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