From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams 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 12:43:50 -0700 (PDT) Message-ID: <45c210aa-5a57-45f7-9bd4-752876b233c2@default> References: << <83muut9q8m.fsf@gnu.org> >> <<<83in5ga7dc.fsf@gnu.org>>> <<0c4b0a47-267d-4c4d-8d1f-6a562ac7519b@default>> <<837elw9vp9.fsf@gnu.org>> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1531683788 13267 195.159.176.226 (15 Jul 2018 19:43:08 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 15 Jul 2018 19:43:08 +0000 (UTC) Cc: 32159@debbugs.gnu.org, moses.mason@gmail.com To: Eli Zaretskii , Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Jul 15 21:43:03 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 1femv9-0003MT-5Y for geb-bug-gnu-emacs@m.gmane.org; Sun, 15 Jul 2018 21:43:03 +0200 Original-Received: from localhost ([::1]:47328 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1femxG-0001uB-6b for geb-bug-gnu-emacs@m.gmane.org; Sun, 15 Jul 2018 15:45:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53134) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1femx9-0001sa-8L for bug-gnu-emacs@gnu.org; Sun, 15 Jul 2018 15:45:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1femx4-0006FS-Ac for bug-gnu-emacs@gnu.org; Sun, 15 Jul 2018 15:45:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:37053) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1femx4-0006F4-50 for bug-gnu-emacs@gnu.org; Sun, 15 Jul 2018 15:45:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1femx3-0007wF-Ot for bug-gnu-emacs@gnu.org; Sun, 15 Jul 2018 15:45:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 15 Jul 2018 19:45:01 +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.153168384330423 (code B ref 32159); Sun, 15 Jul 2018 19:45:01 +0000 Original-Received: (at 32159) by debbugs.gnu.org; 15 Jul 2018 19:44:03 +0000 Original-Received: from localhost ([127.0.0.1]:42071 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1femw6-0007ud-GY for submit@debbugs.gnu.org; Sun, 15 Jul 2018 15:44:02 -0400 Original-Received: from userp2130.oracle.com ([156.151.31.86]:55480) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1femw4-0007u2-Oi for 32159@debbugs.gnu.org; Sun, 15 Jul 2018 15:44:01 -0400 Original-Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w6FJhtdE050063; Sun, 15 Jul 2018 19:43:55 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=fiky0MHoTV5YhuzR9z+DAcU/rTxLnwuy2980eovCffU=; b=F7hQ2VJbEolXdYwNhZIZlIA7AcJOPu9y+ZYKeboSCk1pjQ4aGlKemoY7SZ2JvtKGE3VF cRuhjRlxOEOTLk3Fm8TdZTM1r8K+kETVQBWB71DycVH48GTU+oUmvBhwzQ2ycYWVUL65 CBN1xbNkMsFOq0S//gKqEgrU4+lzDwAyUuJsNuBM6cq3iH09YVPkRQC0kjQmt//fRA9m h5i0IV28lRa7QOay26DdL6ibzwVDUn31CXZBkA0Dl0at10wb9HtcM52AvCDkYcbMCiwm ZOKFsvwvkHxRiZb/iCnglwcWURXiFy8NRhnn+fukVMm9dT9lokP0PwD8wZkgiclFLRiJ Ng== Original-Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp2130.oracle.com with ESMTP id 2k7a3t26p2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 15 Jul 2018 19:43:54 +0000 Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w6FJhrnx004055 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 15 Jul 2018 19:43:53 GMT Original-Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w6FJhpQR027730; Sun, 15 Jul 2018 19:43:52 GMT In-Reply-To: <<837elw9vp9.fsf@gnu.org>> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4717.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8955 signatures=668706 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807150237 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:148549 Archived-At: > 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. How is a user to know which characters are problematic, and thus perhaps to tell Emacs that s?he doesn't want/need those chars to be displayed? How is a user to tell Emacs that s?he doesn't want/need this or that char to be displayed? > > 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. >=20 > We have that way: the user should customize the fontset. How does a user do that? How does a user know that that is what needs to be done? Just what is a user supposed to do, when s?he determines that Emacs hangs (is slow) because it tries to search fonts? > And what exactly is "going on", may I ask? You tell me. As a user, the symptom is hanging/slowdown. > > Doesn't (can't) Emacs have a better understanding of > > this problem than a user? >=20 > 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? Why would Emacs need to do that over and over? Can't it record that failure, so it doesn't try again in a future session? > > Can't Emacs learn which fonts work for which chars, >=20 > It can, and it has. See the default fontset -- that's the database > Emacs uses to guide the search. I don't know how to "see" it or what to do when I do see it. But a naive guess would be that the default font set isn't sufficient, if Emacs keeps hanging. > > 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? >=20 > Emacs never tries to search for a font that supports a given character > after it has done that once and failed. Even across Emacs sessions? Does it remember that that happened, so it doesn't try the same font for the same char in a future session? If so, great. In that case, I don't see why it keeps on hanging (slowdown). > But it will look again when > presented with another character, or if we clear the font caches. Is clearing the font caches something a user does (without knowing it)? Am I the one doing that somehow? Based on what you said in other threads, I've already set `inhibit-compacting-font-caches' to nil, but that doesn't seem to have fixed the problem. > > 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. >=20 > 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; So it's about installing more fonts, not uninstalling fonts because there are too many. Good to know, I guess. I'll gladly install one or two more fonts. I just need to know what they are and where to get them. You've often mentioned Symbola, but I installed that long ago, and it doesn't seem to have made any difference. > if the user doesn't _want_ those characters to be displayed, ever, Dunno what the chars are. But yes, if some char is causing Emacs to hang, in spite of the many fonts I have installed, then at this point I'd say that it should be ignored: no attempt made to display it. Is there no way to just tell Emacs that, as a general rule: don't bother trying to display any chars that you've previously tried and failed to display? Above, you seem to say that Emacs already does that, but it's not clear whether you meant in the same Emacs session or persistently. If it already does that across Emacs sessions then I don't understand why the problem persists. It seems like it would have already learned by now that there is no sense wasting time trying to (again) look for a font to display such a char. > there's a way of customizing Emacs to do that as well. What way is that? > Doing none of those alternatives makes no > sense to me, if the slowdown annoys the user who is in this situation. Those alternatives are not clear to me. Perhaps you could post some instructions somewhere, for what to do if Emacs hangs because it tries to find a suitable font? > > 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". >=20 > 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. Yes, that's too bad. But I didn't see the problem in older releases. At some point (relatively recently, but I don't recall which release it was - perhaps you do), the problem began. > > I expect that you, Eli, are likely our only hope > > anytime soon of addressing this problem. >=20 > 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. OK; please do that. It's not clear to me what a user should try. > That, and applying some simple band-aid, like > inhibit-compacting-font-caches, from time to time, is > all I can do, and am doing. OK; thanks for that. I did set that particular variable to nil when you first mentioned it. > > 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. >=20 > 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. That's true. But some users, such as myself, may have installed fonts that they don't really need and not know exactly which fonts they might need for this or that application. > 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. I'd like to know more about each of those possibilities. I know nothing about the second (customizing fontsets). Wrt the first, I already installed font Symbola. I thought you had indicated that that font should take care of most chars Emacs itself tends to present to users (e.g. in `Hello'). But installing Symbola didn't seem to help. > > 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? >=20 > 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. Do you have an idea why Emacs, but not other applications, seems to have this problem? You indicated in your answer earlier that it's because Emacs does much more than others. If that's the reason, is there a way for a user to dial back some of that much-more that Emacs does? Is there a way for a user to get, in Emacs, the inferior-but-not-hanging behavior of other applications?