Re: Progress bars + events [Re: crash when using W3]
the problem here is andy's event code.
andy, i'm not sure i really believe that you need to cycle the event code to get
widgets to redisplay, but in any case you should
(1) hide the logic to do this in the c code; the lisp code should do nothing
other than call (redisplay widget)
(2) make sure your event-cycling code processes *NO* events at all. this
includes non-user events. queue the events instead.
in other words, dispatch-non-command-events must go, and i am proposing a
general function (redisplay OBJECT) to replace the existing ad-hoc functions.
Jan Vroonhof wrote:
Ben Wing <ben(a)666.com> writes:
> we wouldn't need to inhibit event processing. bill perry would get a lisp
> error upon buffer deletion, and would then have to change his code not to
> trigger event processing in after-change.
We have a catch-22 here. The code is that is triggering the event processing
is to display progress bars and Andy's says event processing is NEEDED there
:-(
It doesn't even help to inhibit process events because for instance the GPM
code (text based mouse support) uses them.
May we should simply start by signalling an error and see what breaks..
Jan
--
Ben
In order to save my hands, I am cutting back on my mail. I also write
as succinctly as possible -- please don't be offended. If you send me
mail, you _will_ get a response, but please be patient, especially for
XEmacs-related mail. If you need an immediate response and it is not
apparent in your message, please say so. Thanks for your understanding.
See also http://www.666.com/ben/typing.html.