bug#22519: 25.1.50; Emacs gets stuck while doing incremental search forward

[Eli Zaretskii <eliz@gnu.org>]

> From: vincent.belaiche@gmail.com (Vincent Belaïche)
> Cc: Vincent Belaïche <vincent.belaiche@gmail.com> ,
>  22519@debbugs.gnu.org
> Date: Wed, 16 Mar 2016 12:16:00 +0100
> 
> > IOW, I still cannot reproduce the problem on my system.  I suspect
> > some issue with your font configuration, but that's just a guess.
> 
> I have the same type of suspicion that it has to do with the display. Ie
> some code running outside Emacs in some standard system library of
> Windows API. However, there may also be some suboptimal coding in the
> ways that Emacs, or some graphic library used by Emacs, interacts with
> these library fuctions.
> 
> I have attached a picture of my display, as you see I have a few not
> displayable characters. They are displayed with small retangles
> containing the Unicode code point in 4 hexadecimal letters --- let us
> call this an hexa-rectangle.
> 
> My speculation is that every time MSWindows is requested for such not
> displayable character, then it spends a lot of time seeking whether this
> character can be displayed in any of the supported fonts, and if not, it
> spends again time making on the fly the special hexa-rectangle
> characters, or maybe those hexa-rectangle bitmaps are placed in some
> memory area that is not fast enough...
> 
> So, do you have also any hexa-rectangles displayed on your system ?

Only one.  All the rest are displayed correctly.

Do you have the Symbola font installed?  If not, I suggest to install
it, then I expect your problem to go away.  If you need to work a lot
with mathematical symbols, having Symbola installed is a must, IMO.

> Maybe you could try and reproduce the problem by replacing in the file
> some of the math symbols by characters that are not displayable on your
> machine. E.g. you could do some `M-: (insert (string #xhhhh)) RET' with
> hhhh in { FFF0, FFC0, FFD0, FFC1, FFD1, FFE7, FFC8, FFD8, FFC9, FFD9,
> FFDD, FFDE, FFBF, FFDF, FFEF, 0380, 0381, 0382, 03A2, 0383, 0377, 0378,
> 038B, 038D}, based on taking greyed cells from page 2 of these
> documents:
> 
>    http://www.unicode.org/charts/PDF/UFF00.pdf
>    http://www.unicode.org/charts/PDF/U0370.pdf

I don't see the point of such a test.  What would it demonstrate?

> BTW, even if we end up concluding that the problem is some sort of MSW
> bug, I still think that there is also something in Emacs: now the `Emacs
> stuck' does not happen so often, maybe this is due to this that there
> has been some MSW update meanwhile, but still it can happen after system
> wake-up.

If you are talking about the fact that Emacs searches for a character
in any fonts it thinks might be able to display it, then this isn't a
bug.  What else could Emacs do, when presented with a character that
cannot be displayed with fonts that are already loaded?