From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#21028: Performance regression in revision af1a69f4d17a482c359d98c00ef86fac835b5fac (Apr 2014). Date: Thu, 22 Dec 2016 20:04:35 +0200 Message-ID: <834m1v2630.fsf@gnu.org> References: <559F9FAF.8090708@live.com> <56D7DCC6.9060003@live.com> <56D7E2F6.2020008@live.com> <56D7E8D6.6080508@live.com> <831t7r1f41.fsf@gnu.org> <5ce0aa39-8a49-5cfd-2eac-343fae4505a1@live.com> <83fur3ysvk.fsf@gnu.org> <83dde388-a342-ed1e-1242-7953d9a0f525@gmail.com> <83lgx9ua9x.fsf@gnu.org> <389383ed-ce95-a558-e441-ba7cfa58d58e@gmail.com> <83bmy5u6qo.fsf@gnu.org> <2fd3e21c-37b9-d559-6306-4e8adebad3d5@gmail.com> <831sz0sfug.fsf@gnu.org> <83oa095eaw.fsf@gnu.org> <83lgvd581m.fsf@gnu.org> <83a8br6hq0.fsf@gnu.org> <672a0c69-4352-735f-cba4-025e642626ea@gmail.com> <83vauf50wb.fsf@gnu.org> <7408d59c-92ba-b879-5ac1-3cd5eee9b4db@gmail.com> <83tw9z4zzp.fsf@gnu.org> <2cad0da9-c931-b547-07bb-efec2f2bcf1f@gmail.com> <83h95w0w3p.fsf@gnu.org> <27853273-e6d8-077e-b9e0-b2bec2fe1fae@gmail.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1482429980 16583 195.159.176.226 (22 Dec 2016 18:06:20 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 22 Dec 2016 18:06:20 +0000 (UTC) Cc: 21028@debbugs.gnu.org To: =?UTF-8?Q?Cl=C3=A9ment?= Pit--Claudel Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Dec 22 19:06:16 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 1cK7kn-00035D-68 for geb-bug-gnu-emacs@m.gmane.org; Thu, 22 Dec 2016 19:06:09 +0100 Original-Received: from localhost ([::1]:35574 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cK7kr-0007Sk-Ff for geb-bug-gnu-emacs@m.gmane.org; Thu, 22 Dec 2016 13:06:13 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60966) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cK7kl-0007SZ-BB for bug-gnu-emacs@gnu.org; Thu, 22 Dec 2016 13:06:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cK7kg-0000P9-PY for bug-gnu-emacs@gnu.org; Thu, 22 Dec 2016 13:06:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:36434) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cK7kg-0000P4-LT for bug-gnu-emacs@gnu.org; Thu, 22 Dec 2016 13:06:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cK7kg-0002rp-FC for bug-gnu-emacs@gnu.org; Thu, 22 Dec 2016 13:06:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 22 Dec 2016 18:06:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21028 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 21028-submit@debbugs.gnu.org id=B21028.148242991510966 (code B ref 21028); Thu, 22 Dec 2016 18:06:02 +0000 Original-Received: (at 21028) by debbugs.gnu.org; 22 Dec 2016 18:05:15 +0000 Original-Received: from localhost ([127.0.0.1]:51833 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cK7jv-0002qo-CC for submit@debbugs.gnu.org; Thu, 22 Dec 2016 13:05:15 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:41380) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cK7jt-0002qa-VV for 21028@debbugs.gnu.org; Thu, 22 Dec 2016 13:05:14 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cK7jj-0008GE-1k for 21028@debbugs.gnu.org; Thu, 22 Dec 2016 13:05:08 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:38946) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cK7ji-0008G5-UL; Thu, 22 Dec 2016 13:05:02 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1215 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cK7jh-0000J3-Ps; Thu, 22 Dec 2016 13:05:02 -0500 In-reply-to: <27853273-e6d8-077e-b9e0-b2bec2fe1fae@gmail.com> (message from =?UTF-8?Q?Cl=C3=A9ment?= Pit--Claudel on Thu, 22 Dec 2016 11:49:09 -0500) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:127338 Archived-At: > Cc: 21028@debbugs.gnu.org > From: Clément Pit--Claudel > Date: Thu, 22 Dec 2016 11:49:09 -0500 > > I did; append works fine here. Everything is displayed with XITS Math, as expected. prepend uses Segoe or XITS for all text, which I don't want. It's good for testing, though, since I guess that otherwise your Emacs picks other fonts that are available on your machine. Yes, that's why I used that. I have Symbola installed, and it is used for all those characters unless I use prepend, and the problem doesn't happen. > If you see the slowdown, then it seems that managed to reproduce the problem, right? No, not really. It doesn't seem useful to define a font that is only used for blanks and can support no other characters in the buffer, because that probably means Emacs is desperately trying to use it and fails, which can explain the slowdown. > Is there anything preventing us from applying the fix that you described last month? You have to convince me it's needed ;-) Is the other font a necessary part of this problem? IOW, if you only setup the fontset with the Segoe UI Emoji, does the problem still happen? I didn't try to install the other font, but if doing so is necessary, I will try that. > The example only shows arrows because I tried to make it minimal; my bug report is about the fact that, when I set up Emacs to display characters the way I want them, it gets slow. I readily admit that changing the font set-up may make the problem go away, but it's not a satisfactory solution (I still get support requests from users of my packages about degraded performance due to prettify-symbols-mode, and it's hard to tell them to use different fonts). I agree that changing the font is not a satisfactory solution (unless it turns out the font you've been using is simply broken in some way). But neither does it make sense to make changes in the code we don't understand well enough when it turns out the offending font is not used for any of the characters in the buffer. > The fixes that you suggested to my minimal example do work around the issue in that case (another work around for me is to just remove the Segoe UI line), but these fixes are not applicable to my full font configuration. I can post my full configuration if you want to suggest improvements that would work around the issue in my specific case (alternatively, it's available here: https://github.com/cpitclaudel/.emacs.d/blob/master/init/fonts.el), but this seems like a waste of your time: there's no doubt that others will run into the same issues (indeed, they already do), and fixing their configurations one by one isn't practical (assuming we even hear about them). I would like to try and understand the problem. For that I need a minimal setup that will show the problem while still making sense, i.e. when the characters in the buffer are displayed by the offending font. A setup with a font that is not actually used for display doesn't seem to be sensible; if showing the problem with real characters requires a somewhat more elaborate setup, please show it. One aspect that might make this issue easier to analyze is not to use 'unicode as the target of the fontset, but instead specify range(s) of characters where you want it used. Then the prepend/append issue will go away, and the differences between our systems wrt other fonts will not get in the way of reproducing the problem. Thanks.