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#32159: 26.1; inhibit-compacting-font-caches does not fix all fonts lagging issue Date: Sun, 15 Jul 2018 21:53:54 +0300 Message-ID: <837elw9vp9.fsf@gnu.org> References: < <83muut9q8m.fsf@gnu.org> > <<83in5ga7dc.fsf@gnu.org>> <0c4b0a47-267d-4c4d-8d1f-6a562ac7519b@default> NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1531680799 15822 195.159.176.226 (15 Jul 2018 18:53:19 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 15 Jul 2018 18:53:19 +0000 (UTC) Cc: 32159@debbugs.gnu.org, moses.mason@gmail.com To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Jul 15 20:53:14 2018 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 1fem8w-00042c-AX for geb-bug-gnu-emacs@m.gmane.org; Sun, 15 Jul 2018 20:53:14 +0200 Original-Received: from localhost ([::1]:47176 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1femB3-00031K-5x for geb-bug-gnu-emacs@m.gmane.org; Sun, 15 Jul 2018 14:55:25 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47722) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1femAp-0002wO-2Y for bug-gnu-emacs@gnu.org; Sun, 15 Jul 2018 14:55:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1femAh-00038U-TJ for bug-gnu-emacs@gnu.org; Sun, 15 Jul 2018 14:55:10 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:37036) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1femAh-00037B-7m for bug-gnu-emacs@gnu.org; Sun, 15 Jul 2018 14:55:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1femAg-0006kb-83 for bug-gnu-emacs@gnu.org; Sun, 15 Jul 2018 14:55:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 15 Jul 2018 18:55:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 32159 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 32159-submit@debbugs.gnu.org id=B32159.153168084925883 (code B ref 32159); Sun, 15 Jul 2018 18:55:02 +0000 Original-Received: (at 32159) by debbugs.gnu.org; 15 Jul 2018 18:54:09 +0000 Original-Received: from localhost ([127.0.0.1]:42054 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fem9o-0006jN-AB for submit@debbugs.gnu.org; Sun, 15 Jul 2018 14:54:09 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:56500) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fem9m-0006ir-0r for 32159@debbugs.gnu.org; Sun, 15 Jul 2018 14:54:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fem9a-0002EB-NO for 32159@debbugs.gnu.org; Sun, 15 Jul 2018 14:54:00 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:60420) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fem9Y-0002Dx-UE; Sun, 15 Jul 2018 14:53:53 -0400 Original-Received: from [176.228.60.248] (port=3537 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1fem9X-0002d0-Ei; Sun, 15 Jul 2018 14:53:52 -0400 In-reply-to: <0c4b0a47-267d-4c4d-8d1f-6a562ac7519b@default> (message from Drew Adams on Sun, 15 Jul 2018 09:50:03 -0700 (PDT)) 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:148548 Archived-At: > Date: Sun, 15 Jul 2018 09:50:03 -0700 (PDT) > From: Drew Adams > Cc: 32159@debbugs.gnu.org > > It's great to support a large variety of fonts. But > if a user has lots of fonts installed then it seems > that such an advantage can become a debilitating > (i.e., severe) disadvantage. Only if some characters Emacs needs to display are not supported by any of those many fonts, and if the user didn't customize Emacs to tell that he/she doesn't _want_ those characters to be displayed, ever. How reasonable is such a situation? Not very reasonable from my POV. > This seems like a case of letting a search for the perfect become > the enemy of the good. What is "good" in this context, and how do we define it in practical terms that can allow us to express it in code? > It sounds like Emacs has a do-or-die approach, here, > trying its utmost to find a font that will fit the > bill - and using all installed fonts in its search. No, it doesn't use all of the installed fonts, only those which satisfy the requirements of the script whose character Emacs needs to display. > It seems, at least naively, like it should be > possible for a user to control this, by toning down > Emacs's overdrive and enthusiasm in this. We have that way: the user should customize the fontset. > Emacs had better analyze what's going on, itself, no? And what exactly is "going on", may I ask? Emacs enumerates the relevant fonts, then goes over them one by one, determining as quickly as it can whether each font supports the required features. Each font that does is opened and looked up for the character we need to display. In this context, what do you mean by "going on"? > Doesn't (can't) Emacs have a better understanding of > this problem than a user? What else can Emacs do except try the fonts that might fit the bill? What other understanding do you expect from Emacs? Can Emacs "understand" that no font is available for a given character without trying to find such a font? > IOW, Emacs should learn when to stop hanging a user > up. Which is when, exactly? If you have some ideas, please let us hear them, even if they are vague. > Why must Emacs always try _all installed fonts_ each time? It doesn't, not all of them. Only those that might be relevant. > Can't Emacs learn which fonts work for which chars, It can, and it has. See the default fontset -- that's the database Emacs uses to guide the search. > so that it doesn't keep trying a given font when > trying to display a given char, after it's already > determined previously that that font doesn't support > that char? Emacs never tries to search for a font that supports a given character after it has done that once and failed. But it will look again when presented with another character, or if we clear the font caches. > My question is essentially this: It seems like you > keep saying, and being content to say, that if too > may fonts are installed then Emacs can be slow / hang. I'm saying that a system that has 5000 fonts installed and still has some characters not covered is misconfigured. Installing one or two more fonts will probably fix the problem; if the user doesn't _want_ those characters to be displayed, ever, there's a way of customizing Emacs to do that as well. Doing none of those alternatives makes no sense to me, if the slowdown annoys the user who is in this situation. > I expect that, even if you agree that that would be > desirable (which I'm not sure you do), you might > say only: "patches welcome". Patches to speed up Emacs are always welcome, that's a truism. Sadly, I've not seen patches in this particular are in a long, long, long, LONG time. > I expect that you, Eli, are likely our only hope > anytime soon of addressing this problem. I'm not your hope, I don't know enough about this stuff to redesign it (assuming that there is a way of redesigning it and getting better performance for the same level of support for various scripts). All I can is try to explain how to configure your system better using the available features and tricks about which I do know. That, and applying some simple band-aid, like inhibit-compacting-font-caches, from time to time, is all I can do, and am doing. > Can Emacs not analyze the problem while it searches > desperately for a font, and so be able to report > about which fonts seem the most useless, least used, > and least useful for Emacs? That would help a user > think about which fonts s?he might try removing. >From the little I know, there's no answer to that question, even if you only ask about Emacs. Of course, people install fonts for other applications as well, and might not want to uninstall fonts that get in Emacs's way. No, the way to solve these problems is to either install a few more fonts that complete/improve the coverage, and/or customize the fontsets to make the font search more efficient. > And beyond putting this burden on the user, can't > such an analysis by Emacs be used by Emacs itself, > to help it try to do the right thing by default - > have it try dropping this or that font from its > search? IOW, can't Emacs learn about the set of > fonts installed, and not blindly try each one > everytime when trying to display a given char? We don't have infrastructure for such analysis. And I don't think we have anyone on board with expertise to design and code it, even for a single platform, let alone all of them. "Patches welcome", of course. > Why must the only "solution" be for a user to > uninstall fonts? See above: it's not the only one. Not even the best, if you ask me.