[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#24790: Segmentation fault when changing default font on master

From: Clément Pit--Claudel
Subject: bug#24790: Segmentation fault when changing default font on master
Date: Tue, 25 Oct 2016 16:18:18 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0

On 2016-10-25 15:42, Eli Zaretskii wrote:
>> Cc: address@hidden
>> From: Clément Pit--Claudel <address@hidden>
>> Date: Tue, 25 Oct 2016 15:27:45 -0400
>>>> My Emacs has patch af1a69f4d17a482c359d98c00ef86fac835b5fac reverted.  
>>>> Could this make a difference?
>>> With such a simple reproducer, it's much easier to re-apply the patch
>>> and see if it makes the difference than answer your question by just
>>> looking at your data.
>> Indeed, and it seems that my reversing this patch is what caused the issue 
>> (IOW, I can't crash Emacs any more after re-applying the patch).
> So this report can be closed?

Maybe? See below. Emacs is unusable for me if I don't reverse this patch.

>>> Why do you still have that commit reverted, btw?  I thought the
>>> problem caused by it is nowadays solved: you have a variable to avoid
>>> it.
>> I never heard about that variable :) Which one is it?
> inhibit-compacting-font-caches, see NEWS on the emacs-25 branch.

Setting this to t doesn't make any visible difference to bug 21028.  Was it 
introduced to solve a different problem?

IOW, when I run (building on the example in the 21028 thread)

    src/emacs -Q -mm --eval '(setq inhibit-compacting-font-caches t)' -l 
21028.el 21028 -f prettify-symbols-mode

I get the same speed issues (each redisplay takes > 5 seconds), regardless of 
the value of inhibit-compacting-font-caches.


Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]