* Set inhibit-compacting-font-caches non-nil on MS-Windows
@ 2019-08-03 12:20 Eli Zaretskii
2019-09-07 9:27 ` Eli Zaretskii
2019-09-13 12:14 ` Stefan Kangas
0 siblings, 2 replies; 6+ messages in thread
From: Eli Zaretskii @ 2019-08-03 12:20 UTC (permalink / raw)
To: emacs-devel
I think we should make this variable non-nil by default on
MS-Windows.
There are quite a few bug reports in the bug DB which all complain
about slow redisplay on MS-Windows, and were resolved by setting this
variable non-nil. So it sounds like on MS-Windows the compacting of
the font caches is not a good idea (the original code was written to
fix a problem observed on X).
Any objections/comments?
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: Set inhibit-compacting-font-caches non-nil on MS-Windows
[not found] <<83a7cqe8yh.fsf@gnu.org>
@ 2019-08-03 15:06 ` Drew Adams
2019-08-03 17:54 ` Andy Moreton
0 siblings, 1 reply; 6+ messages in thread
From: Drew Adams @ 2019-08-03 15:06 UTC (permalink / raw)
To: Eli Zaretskii, emacs-devel
> I think we should make this variable non-nil by default on
> MS-Windows.
>
> There are quite a few bug reports in the bug DB which all complain
> about slow redisplay on MS-Windows, and were resolved by setting this
> variable non-nil. So it sounds like on MS-Windows the compacting of
> the font caches is not a good idea (the original code was written to
> fix a problem observed on X).
+1. Bugs #30539 and #32159, for instance.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Set inhibit-compacting-font-caches non-nil on MS-Windows
2019-08-03 15:06 ` Drew Adams
@ 2019-08-03 17:54 ` Andy Moreton
0 siblings, 0 replies; 6+ messages in thread
From: Andy Moreton @ 2019-08-03 17:54 UTC (permalink / raw)
To: emacs-devel
On Sat 03 Aug 2019, Drew Adams wrote:
>> I think we should make this variable non-nil by default on
>> MS-Windows.
>>
>> There are quite a few bug reports in the bug DB which all complain
>> about slow redisplay on MS-Windows, and were resolved by setting this
>> variable non-nil. So it sounds like on MS-Windows the compacting of
>> the font caches is not a good idea (the original code was written to
>> fix a problem observed on X).
>
> +1. Bugs #30539 and #32159, for instance.
I don't see this problem in my usual setup on Windows, probably because
I have configured the fonts used in `fontset-default', resulting in
shorter searches for suitable fonts.
As Eli pointed out in a previous discussion, configuring the default
fontset to contain the right fonts for multiple versions of Windows is a
fair amount of work, and would require ongoing maintenance.
Given that, setting inhibit-compacting-font-caches non-nil on Windows
seems a pragmatic workaround.
AndyM
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Set inhibit-compacting-font-caches non-nil on MS-Windows
2019-08-03 12:20 Set inhibit-compacting-font-caches non-nil on MS-Windows Eli Zaretskii
@ 2019-09-07 9:27 ` Eli Zaretskii
2019-09-13 12:14 ` Stefan Kangas
1 sibling, 0 replies; 6+ messages in thread
From: Eli Zaretskii @ 2019-09-07 9:27 UTC (permalink / raw)
To: emacs-devel
> Date: Sat, 03 Aug 2019 15:20:54 +0300
> From: Eli Zaretskii <eliz@gnu.org>
>
> I think we should make this variable non-nil by default on
> MS-Windows.
>
> There are quite a few bug reports in the bug DB which all complain
> about slow redisplay on MS-Windows, and were resolved by setting this
> variable non-nil. So it sounds like on MS-Windows the compacting of
> the font caches is not a good idea (the original code was written to
> fix a problem observed on X).
>
> Any objections/comments?
No objections, so I've now made such a change on master.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Set inhibit-compacting-font-caches non-nil on MS-Windows
2019-08-03 12:20 Set inhibit-compacting-font-caches non-nil on MS-Windows Eli Zaretskii
2019-09-07 9:27 ` Eli Zaretskii
@ 2019-09-13 12:14 ` Stefan Kangas
2019-09-13 12:35 ` Eli Zaretskii
1 sibling, 1 reply; 6+ messages in thread
From: Stefan Kangas @ 2019-09-13 12:14 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
> I think we should make this variable non-nil by default on
> MS-Windows.
>
> There are quite a few bug reports in the bug DB which all complain
> about slow redisplay on MS-Windows, and were resolved by setting this
> variable non-nil. So it sounds like on MS-Windows the compacting of
> the font caches is not a good idea (the original code was written to
> fix a problem observed on X).
>
> Any objections/comments?
Since there have been no objections, perhaps it's time to do this change?
Best regards,
Stefan Kangas
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Set inhibit-compacting-font-caches non-nil on MS-Windows
2019-09-13 12:14 ` Stefan Kangas
@ 2019-09-13 12:35 ` Eli Zaretskii
0 siblings, 0 replies; 6+ messages in thread
From: Eli Zaretskii @ 2019-09-13 12:35 UTC (permalink / raw)
To: Stefan Kangas; +Cc: emacs-devel
> From: Stefan Kangas <stefan@marxist.se>
> Date: Fri, 13 Sep 2019 14:14:31 +0200
> Cc: emacs-devel@gnu.org
>
> Since there have been no objections, perhaps it's time to do this change?
Already done in f34f49f35, and announced in
https://lists.gnu.org/archive/html/emacs-devel/2019-09/msg00177.html.
Thanks.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-09-13 12:35 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-08-03 12:20 Set inhibit-compacting-font-caches non-nil on MS-Windows Eli Zaretskii
2019-09-07 9:27 ` Eli Zaretskii
2019-09-13 12:14 ` Stefan Kangas
2019-09-13 12:35 ` Eli Zaretskii
[not found] <<83a7cqe8yh.fsf@gnu.org>
2019-08-03 15:06 ` Drew Adams
2019-08-03 17:54 ` Andy Moreton
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).