bug#23377: 25.0.93; Completion is extremely slow for insert-char

[Drew Adams]

> > if the main reason to disable it is for performance in
> > an extreme use case (C-x 8 RET TAB)
> 
> It's not that extreme. It's natural for a user to get the
> whole list and then use C-s to find the desired character.

"Natural" or not is primarily opinion-based.

I sometimes do something similar, so yes, there are times
when you might want to do that.  I submit that someone who
does it regularly is exceptional however, hardly typical.

That is, asking Emacs, each time (or even most of the time
or much of the time), to show you all of the Unicode chars
along with their names, is exceptional.

There is nothing wrong with a user choosing _not_ to show
the chars by default - absolutely nothing.  The question is
what the _default_ Emacs behavior should be for users in
general.  (But the more important question is, again whether
to provide a user option.)

> Also, there's a problem even in less-"extreme" cases. I just
> now tried 'C-x 8 RET B TAB', which lists every character whose
> name starts with "B",

which filters out the _vast_ majority of candidates -
lots of them.  And that's just from typing ONE char.

> and this took about 18 s on my platform,

How long did `C-x 8 RET TAB' take? ;-)

Even just typing one char makes a huge difference.  Type
two and the difference is hugely huge.  Type three ...
four ...

> whereas with Emacs 24.5 it is almost instantaneous.

Isn't it almost instantaneous if the char display is
turned off (in Emacs 25)?  IOW, disabling the new
feature should provide the same performance as before.
If it does not then yes, there is likely a bug here to
be fixed.

But if it is the same, and the slowdown comes only from
displaying the named characters, then it is not clear
that there is a bug.  By displaying the chars you are
asking Emacs to do more work.

> 18 s is waayyy to slow for this sort of user interaction.

What sort of user interaction?  What do you expect, from
typing only `B'?  As you can see when you hit TAB after
`B', there are still lots of candidate chars, and you
are asking Emacs to display all of them.

> Stefan's suggestion of a config var sounds good.

Yes, it's obvious.  It should be a user config var,
IOW an option.

FWIW, I have some experience with this, as Icicles
has had a similar option for many years.  IMO, being
able to see the matching chars is extremely helpful
(and in the case of Icicles, it is enabled by default).

But of course if it is enabled then you might not want to
be doing things like `C-x 8 RET TAB' or `C-x 8 RET B TAB'.

And you might need to be told that, in the doc string.
And you certainly should be told about the option to
turn off such costly-but-useful behavior.

Using `C-x 8 RET TAB' and the like can be reasonable
(though still not very useful) when the option is
disabled.  But doing that makes ~zero sense when it
is enabled.  Users need to know this, yes.

And yes, there are other design possibilities, including,
say, treating the char display when it is enabled as if
it were disabled, until you've typed at least N chars.
In such a design, the non-nil option value could be a
number (min # of chars).

> It's a bit late to be adding features to the emacs-25
> branch, though, so I'm inclined to revert in emacs-25
> (with a "do not merge to master") and add a customizable
> var in master.

Add the user option.  And add some guidance to the doc.
I see no reason to revert the feature or to disable it
by default.

(But to be clear, I really don't care, personally - I use
Icicles.)

-- (FWIW #1) --

With Icicles, `C-x 8 RET B TAB' takes only about 1 sec,
not 18 sec.

Dunno why the difference from what you report.  Maybe it
has to do with the font used - mine shows a lot of the
hex rectangles for BALINESE*, BAMUM*, BRAHMI* etc. chars,
because my default font doesn't support them.  It shows
2093 candidates altogether.  Most of them do display the
char, not a hex rectangle, however.

`C-x 8 RET TAB' takes about 15 sec, for 38830 candidates.

And Icicles spends some extra time composing mouseover
text and mode-line text help.

(However, that's with Emacs 24.5.  I cannot use Emacs 25
for this because 25 crashes on me all the time.  But
unless the Emacs 25 code does something different for
`ucs-names' itself, it should not affect the Icicles code.
So I will expect the same kind of time, once I find an
Emacs 25 build that doesn't crash.)

-- (FWIW #2) --

Option doc.  (Note the bit of advice at the end, about _not_
doing things like `C-x 8 RET TAB'.)

--

 icicle-read-char-by-name-multi-completion-flag is a variable
 defined in `icicles-opt.el'.  Its value is t

 Documentation:
 Non-nil means `icicle-read-char-by-name' uses multi-completion.
 If nil then a candidate is just as in vanilla Emacs.
 If non-nil then it is a 3-part multi-completion: NAME CODE CHAR,
 showing three ways to represent the character as text:

 * NAME is the Unicode name
 * CODE is the Unicode code point, as a hexidecimal numeral
 * CHAR is the char itself (as it appears in text, not as an integer)

 In addition, if non-nil then properties `help-echo' and
 `icicle-mode-line-help' are put on NAME, showing both NAME and the
 code point (in hex, octal, and decimal).

 Setting this option to nil can speed up reading a character
 considerably, but it does not give you the advantages of seeing the
 character (WYSIWYG) or matching its code point.

 Instead of using a nil value, you can also speed things up by:
 * turning off incremental completion
 * choosing a strong input pattern, before asking for candidate
   matching.

 You can customize this variable.

--

(The behavior is not quite the same as for vanilla Emacs.
You can complete against the code point or even the displayed
char, not just against its name - or complete against any
combinations of the three.  You can, e.g., complete against
a char such as `;' to see its name and code point.)