No subject

may want to suppress the calling of the external error handling when an error
occurs. This allows status to be returned on a call at the cost of the call
being synchronous (though most such routines are query operations, in any case,
and are typically programmed to be synchronous). When Xlib detects a protocol
error in _XReply(), it calls your procedure ..."

If I take that literally it means that I should force my call to be synchronous
in order to be able to suppress errors.

I really don't know what the original intentions of Xlib designers have been.
It seems a little bit silly to me that there isn't any good way to generally
suppress errors in Xlib without doing some tricks. That odd behaviour is
certainly not desirable in my opinion, but it's impossible to say if error
detection was limited to _XReply and not to general handling of replies on
purpose.

> Now, I can't close the bug yet, because there are two cases where Xlib built
> --with-xcb still won't consult with the extension error handlers: for requests
> issued while an async_handler is queued, and for connections where
> XSetEventQueueOwner has been used to let XCB do all event handling. (This is
> the "if(req && xcb_poll_for_reply..." case in process_responses.)
> 
> I can fix those cases trivially, but supporting the above odd behavior at the
> same time requires some refactoring.

Thanks for fixing this, I can live with the synchronous error handling but
can't really say if the odd behaviour should be preserved.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.