From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Klaus-Dieter Bauer Newsgroups: gmane.emacs.bugs Subject: bug#24918: 25.1; Fonts can make Emacs grind to a halt Date: Thu, 1 Dec 2016 11:21:36 +0100 Message-ID: References: <8360nvfedz.fsf@gnu.org> <83inrue97n.fsf@gnu.org> <83lgwc96nn.fsf@gnu.org> <83lgw3zjvf.fsf@gnu.org> <83inr6xjnv.fsf@gnu.org> <83vav5r5tp.fsf@gnu.org> <83r35tqafy.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/related; boundary=94eb2c1a077a92f6e00542963192 X-Trace: blaine.gmane.org 1480587799 20802 195.159.176.226 (1 Dec 2016 10:23:19 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 1 Dec 2016 10:23:19 +0000 (UTC) Cc: 24918@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Dec 01 11:23:12 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cCOWE-0003oo-Ap for geb-bug-gnu-emacs@m.gmane.org; Thu, 01 Dec 2016 11:23:10 +0100 Original-Received: from localhost ([::1]:55329 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cCOWG-0002vp-D4 for geb-bug-gnu-emacs@m.gmane.org; Thu, 01 Dec 2016 05:23:12 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38106) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cCOW9-0002vY-6h for bug-gnu-emacs@gnu.org; Thu, 01 Dec 2016 05:23:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cCOW6-0002R5-DU for bug-gnu-emacs@gnu.org; Thu, 01 Dec 2016 05:23:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:60932) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cCOW6-0002Qz-A6 for bug-gnu-emacs@gnu.org; Thu, 01 Dec 2016 05:23:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cCOW6-0005rJ-4b for bug-gnu-emacs@gnu.org; Thu, 01 Dec 2016 05:23:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Klaus-Dieter Bauer Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 01 Dec 2016 10:23:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24918 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 24918-submit@debbugs.gnu.org id=B24918.148058773522453 (code B ref 24918); Thu, 01 Dec 2016 10:23:02 +0000 Original-Received: (at 24918) by debbugs.gnu.org; 1 Dec 2016 10:22:15 +0000 Original-Received: from localhost ([127.0.0.1]:48098 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cCOVL-0005q5-8u for submit@debbugs.gnu.org; Thu, 01 Dec 2016 05:22:15 -0500 Original-Received: from mail-lf0-f46.google.com ([209.85.215.46]:35879) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cCOVJ-0005po-Nx for 24918@debbugs.gnu.org; Thu, 01 Dec 2016 05:22:14 -0500 Original-Received: by mail-lf0-f46.google.com with SMTP id t196so168121513lff.3 for <24918@debbugs.gnu.org>; Thu, 01 Dec 2016 02:22:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NFUMb0IRjuEOJSVuDOPFCqYGG+oNi3gH+FEtvApBzz0=; b=NGQUt5YSG/dK7teJVFKfQpMhX8CZxqQCoO08bBVKlgoz3vE3toVGvMvdrdXMBPLPdr AHOLJq3VVPXYasKTJxM8qiB2jyK4DvP2vJwtm6YKoX8Bu1fv3XIxSzENRG32K15+wGY8 LxJkWd/hmgt8fgVhFTaH+MAvlHuwPw1VA7eRssI+CFOA/enEuMGJCs1xnrwyN3f5GucT sFLEDF18HBtRVku4XN9dO0J6bhrz9ejYi2MOY17bwH9/lv4Sybo0/GV5Ptx30uYpbzdY ZnuD1tCMhc3BeXFZY+8KD2GEAvK0730lCwqmjvp993WdLERdQA86j40KMP2XE4XtOe3G dWzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NFUMb0IRjuEOJSVuDOPFCqYGG+oNi3gH+FEtvApBzz0=; b=X6X40VTIzNXpQv8sdCGutCloZ/NoFNzYFGs4l3ZvZBcvTqGifPGLN+w0epwMIjRaOa XDft2wOo5x40F8HlnWdXrtcb6Z8kzfVSlwrB4HwEpTEGaHJV176exPbIsvN7Hnl/zFtH nNNpzuFyDVw2yINSUkAotwB7jQioumGeu65LiT9HBPHwFTJZHdm0KeAVAguy3wiPFx54 B+9k1il+2qIKHPPlqgzULh5f5JNY432uIlWyyYijQYf5uX62EqRuNmslCCTta2YSb4XL bSy9IrUR/0YntWGG9ox/AlQvBhA3uFKOTyWaSBZSBTpt1f4mavBLEcDU+ZcgNvsDwyvz 7QpQ== X-Gm-Message-State: AKaTC03ygsibWUj4cddQ+0VjospsvVHGvoQac6QU9EWuhU2ZyY2P/yIwbYEXa4/yKXFR8qTPBoTgnfsgjUO3Vw== X-Received: by 10.25.66.213 with SMTP id p204mr16020473lfa.110.1480587727787; Thu, 01 Dec 2016 02:22:07 -0800 (PST) Original-Received: by 10.25.203.6 with HTTP; Thu, 1 Dec 2016 02:21:36 -0800 (PST) In-Reply-To: <83r35tqafy.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:126351 Archived-At: --94eb2c1a077a92f6e00542963192 Content-Type: multipart/alternative; boundary=94eb2c1a077a92f6dc0542963191 --94eb2c1a077a92f6dc0542963191 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2016-11-30 16:00 GMT+01:00 Eli Zaretskii : > > From: Klaus-Dieter Bauer > > Date: Wed, 30 Nov 2016 11:01:32 +0100 > > Cc: 24918@debbugs.gnu.org > > > > I now installed Symbola. In the real-world cases it solves the problem, > but apparently it is not a full solution; > > Possibly sufficient for practical use, but mostly more efficient at > masking the issue. (See especially the > > example below, where the issue occurs even when no fonts are available > at all for a character.) > > > > E.g. I used > > > > (with-selected-window > > (display-buffer (get-buffer-create "*foo*")) > > (goto-char (point-max)) > > (cl-loop for _ upto 1000 ;; lower the limit if it crashes emacs > > with lmt =3D (+ 1 (max-char)) > > for s =3D (string (random lmt)) > > for col =3D (- (point) (line-beginning-position)) > > if (< 30 col) do (insert "\n") > > do (insert s))) > > > > to generate random unicode characters; For most no font is found at all > (a hex-rectangle is displayed instead) > > display: no font available > > but some characters will be generated, where problematic fonts still > come up. > > If you need those characters to be displayed faster, you need to > configure your default fontset to cover them with Unicode fonts. The > default fontset setup in Emacs tries not to get in the way of users > with too many special fonts, so not all the ranges are covered, unless > there are good free fonts for them. > > > Additionally, one generated line was also heavily laggy, despite all > characters saying "no font available", i.e. > > even without font substitution. I attached the line as > "problematic-line.txt". Navigating into or out of this line =E2=80=93 or > > from one character to the next, for about half the characters in the > line, talks roughly 1 second on my system. =E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2= =80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80= =93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93= =E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2= =80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80= =93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93= =E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2= =80=93=E2=80=93 > These characters are all unassigned codepoints (i.e., Unicode did not > yet assign any characters to those codepoints), as you can see in the > buffer shown by "C-u C-x =3D", so their display are not important in any > practical use case. > Thankfully, yes. I meant this to be a testcase for checking if their is an underlying issue beyond font substitution, which I assumed this example indicated, since no font was substituted. Anyway, I figured out that the particular character that caused the issue for *this* file was "(insert (string #xF8DB))", which in Gnu Unifont is displayed as a pencil: [image: Inline-Bild 3] Apparently it is in a "private use" block though. Would it be possible to distribute Symbola along with Emacs for the Windows version, or some other viable unicode fallback font such as GNU Unifont (which by the way also fixes the "random characters" test case)? Program-crashes from unexpected characters, let alone from visiting info-page buffers, definitely shouldn't be out-of-the-box behaviour, and apparently appropriate fonts cannot be safely assumed on Windows. --94eb2c1a077a92f6dc0542963191 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
2016= -11-30 16:00 GMT+01:00 Eli Zaretskii <eliz@gnu.org>:
> From: Klaus-Dieter Bauer <= bauer.klaus.dieter@gmail.co= m>
> Date: Wed, 30 Nov 2016 11:01:32 +0100
> Cc: 24918@debbugs.gnu.org=
>
> I now installed Symbola. In the real-world cases it solves the problem= , but apparently it is not a full solution;
> Possibly sufficient for practical use, but mostly more efficient at ma= sking the issue. (See especially the
> example below, where the issue occurs even when no fonts are available= at all for a character.)
>
> E.g. I used
>
> (with-selected-window
> (display-buffer (get-buffer-create "*foo*"))
> (goto-char (point-max))
> (cl-loop for _ upto 1000 ;; lower the limit if it crashes emacs
> with lmt =3D (+ 1 (max-char))
> for s =3D (string (random lmt))
> for col =3D (- (point) (line-beginning-position))
> if (< 30 col) do (insert "\n")
> do (insert s)))
>
> to generate random unicode characters; For most no font is found at al= l (a hex-rectangle is displayed instead)
> display: no font available
> but some characters will be generated, where problematic fonts still c= ome up.

If you need those characters to be displayed faster, you need to
configure your default fontset to cover them with Unicode fonts.=C2=A0 The<= br> default fontset setup in Emacs tries not to get in the way of users
with too many special fonts, so not all the ranges are covered, unless
there are good free fonts for them.

> Additionally, one generated line was also heavily laggy, despite all c= haracters saying "no font available", i.e.
> even without font substitution. I attached the line as "problemat= ic-line.txt". Navigating into or out of this line =E2=80=93 or
> from one character to the next, for about half the characters in the l= ine, talks roughly 1 second on my system.

=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80= =93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93= =E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2= =80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80= =93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93= =E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2= =80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80= =93=E2=80=93=E2=80=93=C2=A0

=
<= div>
=C2=A0
These characters are all unassigned codepoints (i.e., Unicode did no= t
yet assign any characters to those codepoints), as you can see in the
buffer shown by "C-u C-x =3D", so their display are not important= in any
practical use case.

Thankfully, yes. I = meant this to be a testcase for checking if their is an underlying issue be= yond font substitution, which I assumed this example indicated, since no fo= nt was substituted.=C2=A0

Anyway, I figured out th= at the particular character that caused the issue for this=C2=A0file= was "(insert (string #xF8DB))", which in Gnu Unifont is displaye= d as a pencil:=C2=A03D"Inline-Bild==C2=A0Apparently it is in a "private us= e" block though.

Would it be possible to distribute Sy= mbola along with Emacs for the Windows version, or some other viable unicod= e fallback font such as GNU Unifont (which by the way also fixes the "= random characters" test case)? Program-crashes from unexpected charact= ers, let alone from visiting info-page buffers, definitely shouldn't be= out-of-the-box behaviour, and apparently appropriate fonts cannot be safel= y assumed on Windows.=C2=A0

--94eb2c1a077a92f6dc0542963191-- --94eb2c1a077a92f6e00542963192 Content-Type: image/png; name="image.png" Content-Disposition: inline; filename="image.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: ii_158b9e5ed150fdd4 iVBORw0KGgoAAAANSUhEUgAAAAsAAAATCAYAAABGKffQAAAAnklEQVQ4Ee2S3Q2DMAyEP1ddKkzR CXiEcdIZmICnMEtFd7nKDRERRQjeG8nROT7LPxeTJE6e28p782wMs2z9tEYKWsgTvbUwCC/k9hiN nwRvQ0rqQBAUZyl1jlGXcrTc91ICAnEeoG14DSJhjGvwi6qeN5Ed90+ul3JpGy7taQUXsifMiiHL vCe1MypyScj/w73tMX+ohzjClwa8RP4A9CSoTvXtg4IAAAAASUVORK5CYII= --94eb2c1a077a92f6e00542963192--