[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: antialiasing for emacs
From: |
Chris Gray |
Subject: |
Re: antialiasing for emacs |
Date: |
Mon, 28 Jul 2003 13:22:29 -0700 |
User-agent: |
Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux) |
On Mon, 28 Jul 2003, Stefan Monnier wrote:
>> Chris Gray <address@hidden> writes:
>> > Yep. It happens when I start gnus too. I really don't know why,
>> > and these "async errors" seem very hard to debug.
>>
>> Hmmm, actually, come to think of it, there's a function to make
>> emacs use X `synchronously', which might make debugging easier...
>>
>> x-synchronize is a built-in function.
>> (x-synchronize ON &optional DISPLAY)
>>
>> If ON is non-nil, report errors as soon as the erring request is
>> made. If ON is nil, allow buffering of requests. This is a
>> noop on Mac OS systems. The optional second argument DISPLAY
>> specifies which display to act on. DISPLAY should be either a
>> frame or a display name (a string). If DISPLAY is omitted or
>> nil, that stands for the selected frame's display.
>>
>> -Miles
>
> I don't think it's going to help. The `async error' is generally
> due to missing BLOCK_INPUT statements that lead to Xlib functions
> being called from the signal handler while we're already inside
> an Xlib function.
This is exactly what the problem was. In my patch you will notice
that I had BLOCK_INPUT and UNBLOCK_INPUT commented for some strange
reason. Uncommenting it made the async errors go away.
I want to fix some other things before sending another patch, but
those who are already testing my first patch should know what to do.
Cheers,
Chris
Re: antialiasing for emacs, Marcelo Toledo, 2003/07/27