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: Mon, 16 Jul 2018 17:22:54 +0300 Message-ID: <8336wj9s5d.fsf@gnu.org> References: << <83muut9q8m.fsf@gnu.org> >> <<<83in5ga7dc.fsf@gnu.org>>> <<0c4b0a47-267d-4c4d-8d1f-6a562ac7519b@default>> <<837elw9vp9.fsf@gnu.org>> <45c210aa-5a57-45f7-9bd4-752876b233c2@default> NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1531750865 1550 195.159.176.226 (16 Jul 2018 14:21:05 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 16 Jul 2018 14:21:05 +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 Mon Jul 16 16:21:01 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 1ff4N2-0000Fd-UB for geb-bug-gnu-emacs@m.gmane.org; Mon, 16 Jul 2018 16:21:01 +0200 Original-Received: from localhost ([::1]:52103 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ff4P9-0004UV-UP for geb-bug-gnu-emacs@m.gmane.org; Mon, 16 Jul 2018 10:23:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40733) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ff4P2-0004Tv-4z for bug-gnu-emacs@gnu.org; Mon, 16 Jul 2018 10:23:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ff4P0-0007Fj-7T for bug-gnu-emacs@gnu.org; Mon, 16 Jul 2018 10:23:04 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:38867) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ff4P0-0007FZ-1z for bug-gnu-emacs@gnu.org; Mon, 16 Jul 2018 10:23:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ff4Oz-00076V-Kf for bug-gnu-emacs@gnu.org; Mon, 16 Jul 2018 10:23:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Jul 2018 14:23: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.153175097827298 (code B ref 32159); Mon, 16 Jul 2018 14:23:01 +0000 Original-Received: (at 32159) by debbugs.gnu.org; 16 Jul 2018 14:22:58 +0000 Original-Received: from localhost ([127.0.0.1]:43885 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ff4Ov-00076D-FV for submit@debbugs.gnu.org; Mon, 16 Jul 2018 10:22:57 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:49607) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ff4Ot-00075x-N3 for 32159@debbugs.gnu.org; Mon, 16 Jul 2018 10:22:56 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ff4Ok-00073S-3Y for 32159@debbugs.gnu.org; Mon, 16 Jul 2018 10:22:50 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:46644) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ff4Oj-00073M-Ut; Mon, 16 Jul 2018 10:22:46 -0400 Original-Received: from [176.228.60.248] (port=3578 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ff4Oj-0000Ik-BP; Mon, 16 Jul 2018 10:22:45 -0400 In-reply-to: <45c210aa-5a57-45f7-9bd4-752876b233c2@default> (message from Drew Adams on Sun, 15 Jul 2018 12:43:50 -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:148571 Archived-At: > Date: Sun, 15 Jul 2018 12:43:50 -0700 (PDT) > From: Drew Adams > Cc: moses.mason@gmail.com, 32159@debbugs.gnu.org > > 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? In most cases, those characters are displayed as boxes with hex code inside, to mean no font was found for them. If that's not the case, only trial and error (display text with and without portions of the buffer) will uncover them. > How is a user to tell Emacs that s?he doesn't want/need this > or that char to be displayed? "C-u C-x =" displays the answer to that question, and much more. Whether the user does or doesn't want a given character displayed is up to the user: only users know which scripts they want to be legible in their usage of Emacs. > > We have that way: the user should customize the fontset. > How does a user do that? See the 2 manuals, where they document 'set-fontset-font'. There's a lot of info there, with examples. > How does a user know that that is what needs to be done? They are supposed to read the manuals, and this and similar discussions. > Just what is a user supposed to do, when s?he determines that Emacs > hangs (is slow) because it tries to search fonts? See above. > > And what exactly is "going on", may I ask? > > You tell me. As a user, the symptom is hanging/slowdown. That's Emacs searching for a suitable font. Nothing else is 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? > > 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? It does record the failure, but only for this session. Recording that for future session (a.k.a. "caching") has its own problems: the cache needs to be refreshed when fonts are installed or uninstalled, so it's a mixed blessing. The best way to "cache" the information is to customize the fontset to record user preferences, as discussed here. > > > 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. > > I don't know how to "see" it (Did you try 'apropos'?) "M-x describe-fontset RET RET" will show that. Be prepared for it to take a couple of dozen of seconds: it goes through the entire range of Unicode characters. > or what to do when I do see it. See above and below. > But a naive guess would be that the default font set isn't > sufficient, if Emacs keeps hanging. It's a starting point for further customization and optimization. It is practically impossible to make Emacs OOTB fit every system out there, because the fonts installed on each systems cannot be known in advance. Plus, some popular fonts are not free, and we don't want to advertise/support them by including them in the default fontset. The defaults are supposed to cover the "usual" setups, and indeed IME complaints about this are mostly for rare and exotic use cases. Of course, this particular case might just be one that will trigger some changes in Emacs, I don't know yet. > > > 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. > > Even across Emacs sessions? No, only during the same session. > > 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)? It's part of GC. inhibit-compacting-font-caches disables it. > 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. It fixes a different problem. It doesn't affect the search for a suitable font when a given character needs to be displayed for the first time. > > 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. It's a better solution, if you need to display the characters which appear as boxes and/or those for which Emacs takes a long time to search for a font. An even better solution is to (also) customize your fontset to specify fonts for specific scripts or character code ranges, according to the fonts you have and/or whose appearance you like. That could bypass the search entirely in some cases. > I'll gladly install one or two more fonts. I just need > to know what they are and where to get them. Find the characters that display as boxes, then look for fonts that support those characters, and install one of those fonts. > > if the user doesn't _want_ those characters to be displayed, ever, > > Dunno what the chars are. See above. > 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? It already does that, in the same session. See above about caching. > > there's a way of customizing Emacs to do that as well. > > What way is that? See above and below. > > 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? Fontset customization is not just for "hanging", it's for any situation where Emacs chooses a font that you don't like for some reason, and you want it to choose another one. It also helps to speed up the search for fonts. For example, the following setup speeds up the initial display of HELLO by a factor of 5, from about 20 sec to just 4: (set-fontset-font "fontset-default" 'gujarati '("Shruti" . "iso10646-1")) (set-fontset-font "fontset-default" 'devanagari '("Mangal" . "iso10646-1")) (set-fontset-font "fontset-default" 'kannada '("Tunga" . "iso10646-1")) (set-fontset-font "fontset-default" 'malayalam '("Kartika" . "iso10646-1")) (set-fontset-font "fontset-default" 'oriya '("Kalinga" . "iso10646-1")) (set-fontset-font "fontset-default" 'sinhala '("Iskoola Pota" . "iso10646-1")) (set-fontset-font "fontset-default" 'tamil '("Latha" . "iso10646-1")) (set-fontset-font "fontset-default" 'telugu '("Gautami" . "iso10646-1")) (set-fontset-font "fontset-default" 'tibetan '("Microsoft Himalaya" . "iso10646-1")) (set-fontset-font "fontset-default" 'burmese nil) The fonts mentioned above are those available OOTB on a Windows machine I have here; yours may be different. I collected them using "C-u C-x =" for characters whose presence makes display of HELLO significantly slower. If you don't have a font available for some script and/or don't want that script's characters displayed, you can replace the last argument of 'set-fontset-font' with nil, like I did for 'burmese'. (You can also use ranges of codepoints instead of script symbols; see the doc string of 'set-fontset-font'.) The script of a character is also shown by "C-u C-x =". > 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. The only change was the one that is disabled by 'inhibit-compacting-font-caches'. Other than that, it's probably the fonts you installed. If not, I don't know what could be the reason. > > > 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. > > 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. I don't know how to solve this. You will have to analyze your font-related needs in some systematic way. I find the BabelMap program useful for studying the installed fonts, btw. > > 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). See above. > 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. Symbola may not help for HELLO, but that's not an interesting use case, usually. Symbola does help in many real-life use cases, I see that every day on my systems. > 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. Yes. Emacs optimizes the fonts it chooses for the scripts of the characters it needs to display. > If that's the reason, is there a way for a user to dial > back some of that much-more that Emacs does? Yes, by customizing the fontset; see above,