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

[Vincent Belaïche]

Answers below...

Le 16/03/2016 21:24, Eli Zaretskii a écrit :
>> 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 18:40:40 +0100
>>
>>> 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?
>>
>> I don't this that _this_ as such is a bug, what is more annoying is that
>> the slow-down lasts longer than the first scroll into the area where
>> these characters are.
>
> If the character wasn't found, then it makes sense to try looking up
> the fonts again -- the user could install new fonts since the last
> time.

Yes, but there are several ways to make this polling for new fonts less
annoying:

- it would suffice to raise some character specific flag when a
  character is not found in any font in ordder to prevent subsequent
  search for the same character after an edit, and also to put this
  character in some queue so as to trigger the actual font search
  _again_ for the same character only when Emacs gets the focus.

- there could be some counter incremented every time a character cannot
  be displayed in a known font and alternative font would be extensively
  searched only when this counter is below some threshold, and this
  counter would be periodically reset. This method has however the
  drawback that the display would not be deterministic.

- I am wondering whether it is to the application to make this search,
  the system is supposed to know which fonts have been installed, isn't
  it possible that Emacs just ask to MSW for each character that cannot
  be displayed in the default font to supply the best alternative
  font. Then, since the OS is supposed to know whether or not a new font
  has been installed it may be more efficient in performing this search.

>
>> I could stay on the same region for hours, and whenever I made an
>> edit it was slow --- loosing the WYSIWYGiness of the edition, that
>> is I was seeing the full result of what I had typed one or two
>> seconds after the typing had started.
>
> Every redisplay might trigger another search for a suitable font.  The
> solution really is to install the fonts you need.

I agree that the solution is definitely to install the needed fonts. But
when the slow down occurred to me, I had no idea that this was the
solution. If Emacs had some sort of monitoring about display slow down
caused by non displayable characters and would make some warning to the
user that would certainly be an improvement.

>
> Can we now close this bug?

Would it be agreable if I make the following addition to the manual:

diff --git a/doc/emacs/trouble.texi b/doc/emacs/trouble.texi
index bd347b0..e049bd1 100644
--- a/doc/emacs/trouble.texi
+++ b/doc/emacs/trouble.texi
@@ -148,6 +148,7 @@ Lossage
 * DEL Does Not Delete::   What to do if @key{DEL} doesn't delete.
 * Stuck Recursive::       '[...]' in mode line around the parentheses.
 * Screen Garbled::        Garbage on the screen.
+* Slow Display::          Slow screen refresh.
 * Text Garbled::          Garbage in the text.
 * Memory Full::           How to cope when you run out of memory.
 * Crashing::              What Emacs does when it crashes.
@@ -247,6 +248,25 @@ Screen Garbled
 entry, it is possible that there is a bug in the terminfo entry, or a
 bug in Emacs that appears for certain terminal types.
 
+@node Slow Display
+@subsection Slow screen refresh
+@cindex display, slow
+@cindex refresh, display slow
+@cindex font, missing
+
+  If the display is too slow in refreshing when you scroll to a new
+region, or when you edit the buffer, it may be due to this that some
+characters cannot be displayed in the default font, and Emacs is
+spending too much time in looking for a suitable font to display them.
+
+  You can suspect this if you have several characters that are
+displayed as small rectangles containing a hexadecimal code inside.
+
+  The solution is to install the appropriate fonts on your
+machine. For instance if you are editing a text with a lot of math
+symbols, then installing a font like @file{Symbola} should solve this
+problem.
+
 @node Text Garbled
 @subsection Garbage in the Text
 @cindex garbled text