[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#67155: 30.0.50; (x-synchronize t) garbels display
From: |
Gregor Zattler |
Subject: |
bug#67155: 30.0.50; (x-synchronize t) garbels display |
Date: |
Thu, 16 Nov 2023 13:10:44 +0100 |
* Po Lu <luangruo@yahoo.com> [2023-11-15; 21:10 +08]:
> Eli Zaretskii <eliz@gnu.org> writes:
>>> From: Gregor Zattler <grfz@gmx.de>
>>> Date: Tue, 14 Nov 2023 00:58:21 +0100
>>>
>>> I cannot reproduce with -Q, but evaluating
>>> `(x-synchronize t)' sometimes garbles display. See
>>> attached screenshot. Note: When copying the region
>>> shown in the screenshot and pasting into nano, the text
>>> is correct, not garbled.
>>>
>>> Evaluation of `(x-synchronize t)' is part of the
>>> attempt to capture a usable backtrace for bug#66978.
>>>
>>> Now this display bug is another one. If you have any
>>> ideas how to investigate these I would be happy to help
>>> following instructions.
>>
>> Po Lu, any ideas or suggestions?
>
> Not really, unless you (Gregor) try running Emacs with the X font
> backend for a while, and tell me whether the problem abates then:
>
> (set-frame-parameter nil 'font-backend 'x)
With this setting the display should not be garbled,
although using `(x-synchronize t)'?
This only worked with
(set-frame-parameter nil 'font-backend "x")
so with string instead of symbol.
This display bug showed up a few times till I reported
it -- but not since I made `(x-synchronize t)' part of
my standard setup.
I now enabled `(set-frame-parameter nil 'font-backend
"x")' as part of my setup, but the available fonts are
really not nice. I will see how long I can bear with
them for the sake of catching a backtrace of for
bug#66978, which also did not show up again.
Thanks, Gregor