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 09:50:03 -0700 (PDT) Message-ID: <0c4b0a47-267d-4c4d-8d1f-6a562ac7519b@default> References: < <83muut9q8m.fsf@gnu.org> > <<83in5ga7dc.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 1531673422 30905 195.159.176.226 (15 Jul 2018 16:50:22 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 15 Jul 2018 16:50:22 +0000 (UTC) Cc: 32159@debbugs.gnu.org To: Eli Zaretskii , Moses Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Jul 15 18:50:18 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 1fekDx-0007u0-UT for geb-bug-gnu-emacs@m.gmane.org; Sun, 15 Jul 2018 18:50:18 +0200 Original-Received: from localhost ([::1]:46347 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fekG3-0003dQ-1e for geb-bug-gnu-emacs@m.gmane.org; Sun, 15 Jul 2018 12:52:27 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55243) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fekFO-0003b0-TL for bug-gnu-emacs@gnu.org; Sun, 15 Jul 2018 12:52:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fekEy-0000th-FL for bug-gnu-emacs@gnu.org; Sun, 15 Jul 2018 12:51:39 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:36970) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fekEk-0000pL-0o for bug-gnu-emacs@gnu.org; Sun, 15 Jul 2018 12:51:15 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1fekEf-0001rh-Qx for bug-gnu-emacs@gnu.org; Sun, 15 Jul 2018 12:51: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 16:51: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.15316734167107 (code B ref 32159); Sun, 15 Jul 2018 16:51:01 +0000 Original-Received: (at 32159) by debbugs.gnu.org; 15 Jul 2018 16:50:16 +0000 Original-Received: from localhost ([127.0.0.1]:41988 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fekDv-0001qX-QJ for submit@debbugs.gnu.org; Sun, 15 Jul 2018 12:50:16 -0400 Original-Received: from userp2120.oracle.com ([156.151.31.85]:47148) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fekDt-0001qG-RY for 32159@debbugs.gnu.org; Sun, 15 Jul 2018 12:50:14 -0400 Original-Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w6FGnBqK144537; Sun, 15 Jul 2018 16:50:07 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=H3e46y0siv3aB846EtoFzWnQieIov5rnPazWSncdwew=; b=kzuur03BtjkGPVPxHaHi07TPBgVIpWulHBGnZ75OqC6CKUkkFHpO3r4leNb1ylluyEJi nKADKGyffQTMlEDvhxZdlZB+28iI5aXVf4YbfkEJWiZ1s/wQfJvdqGPj3pHcb8An6B0R AM+vOmvREjxun6hRZM04ItAPdSY4ttVJCTVqFgKG4CLIsUQoF4JvxngrPIRtVPYNzs7W GDmKcetpdsh5w7d5nyybR6J1xFLVH/emz8Q2DLHaNpUvCfORggvpgyDUotY60aQ/DH3b Z2u5jkIGUG26AgCinPTBrtaD0f+wyjEb56Z3erYCPMoSK6qlZYe5FmHqSBC8UW9m6KvP LA== Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp2120.oracle.com with ESMTP id 2k7a3jj27h-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 15 Jul 2018 16:50:07 +0000 Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w6FGo6wh022836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 15 Jul 2018 16:50:06 GMT Original-Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w6FGo59o018557; Sun, 15 Jul 2018 16:50:05 GMT In-Reply-To: <<83in5ga7dc.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-1807150203 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:148543 Archived-At: > > Other editor does not have the similar issue. >=20 > AFAIK, no other editor supports such a large variety of fonts. I'll probably get jumped on for chiming in here ignorantly, but... 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. This seems like a case of letting a search for the perfect become the enemy of the good. 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. 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. Not that individual users should _have_ to do that - I don't think they should have to. But they should be able to do so - and easily. Emacs had better analyze what's going on, itself, no? Doesn't (can't) Emacs have a better understanding of this problem than a user? It knows what it's doing, why, and what the result is - what the problems are. All a user experiences is a hang/slowdown, and all they get when they report a bug is the answer that they likely have too many fonts installed. If such a font search is taking "too long" (as determined by some setting perhaps, settable by users but with a reasonable default value for the average) then (1) searching should stop and (2) future searches should be curtailed earlier. IOW, Emacs should learn when to stop hanging a user up. (Having Emacs do that or not should of course be a user choice - optional.) Are particular fonts problematic, leading to more slowdown/hang? Or is it just the number of fonts installed that is the problem? If particular fonts, then can't Emacs itself learn not to bother with those fonts (for a given user)? Why must Emacs always try _all installed fonts_ each time? Can't Emacs learn which fonts work for which chars, 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? I'm clearly no expert on fonts or Emacs's handling of them. So no doubt some of what I'm writing here makes little sense or betrays misunderstanding. Please take this only as one naive user's plaint. This problem is a big one, even if only for the few (?) users who have many fonts installed. We (users and Emacs developers) should not be satisfied by the conclusion that Emacs is incompatible with having many fonts installed - especially since, as Moses said, "Other editor does not have the similar issue." Even with "too many" fonts installed, Emacs should be at least as good as other editors. 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 trust that that's a fact now. But why should that be a reason for concluding that nothing can be done? That's what seems to be happening, at least: the problem remains, and the prescription seems to be just "Don't do that. Don't install so many fonts." (Or don't use Emacs, I guess.) To me, that's not a solution. I have no idea whether it might be the case that _no_ solution is possible. But it seems like hands have been thrown up, we've given up, and "Nothing to be done" is the response. To those users who do get this "no other editor does this" behavior - whether you think it's great or not-so-great that Emacs does it, this is a severe problem. With no facts or real understanding of the underlying code, it seems to this user like Emacs could/should do better. The status quo is not good, for at least some users. The line is apparently that Emacs does _better_ than other editors because it tries harder to find a font that can display a given char. The fact seems to be that, at least in some cases (e.g. many fonts installed), Emacs, in effect, does _worse_ than other editors. Hence Moses saying, "Other editor does not have the similar issue." A user (I, for example) with many fonts installed does not suffer dead-in-the-water behavior from other editors (in the larger sense, i.e., any text-input, editing, or search context). I never see such a problem, outside Emacs. Never. Can we not find some way to let users choose the Emacs full-force-try approach or an approach used by "other editors"? Can we not find a way for Emacs itself, by default, to use better judgment about how far to take its font-search zeal, so that users do not even have to make such a choice (but still give them the choice)? 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". To which I'd say that this problem seems to have _started_ at a certain point (relatively) recently, but it's been with us for a while now, and no new font expert has stepped forward to tackle it. I expect that you, Eli, are likely our only hope anytime soon of addressing this problem. I hope you might think more about it, realizing that "If it hurts, don't do that" is not a reasonable solution here. Even if a user were prepared to uninstall a bunch of fonts - just to make Emacs happy (usable), it's not clear (to me at least) how s?he would go about that. 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. Otherwise, how to know? 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? Why must the only "solution" be for a user to uninstall fonts? Why can't Emacs be prevented from trying to use some of the installed fonts for its search?