Jason Rumney wrote:
The bugs I refer to here are in the display of the popup menus. The
display of the second popup menu gets garbled very often. I also once
saw that the menus did not open at all. I got an error instead. I have
no idea of why.
Probably not related directly to this, but may be caused by the same
problem that the blocking of redisplay is trying to avoid.
I have seen a bit different things happening here. The most common thing
is that the header in the second popup menu get blanked when you use
up/down arrows.
A bit more alarming perhaps is that I have also seen garbage in the
header. I am not quite sure about when (can't reproduce it now), but I
think it was when the menu second menu first were shown.
If you want to sync the threads, is there an explicit way to do it?
Why can't popup-menu do it?
It is not a simple matter of syncing the threads (the Lisp thread is
paused waiting for the popup menu to complete anyway).
It is the fundamental design of Emacs to be single threaded. Until that
is changed, and every attempt so far hasn't gotten past the stage of
talk, the forced use of multiple threads that Windows imposes on us is
going to present problems.
I am not sure that this has much to do with the fact that Emacs design
is single threaded (though on w32 there is a lisp thread and a gui thread).
The problem seems to be that the gui thread is blocked and can not
update the screen. It looks like (sit-for 9) does not do anything.
I thought that the command choosen from the menu were put in some queue
in the lisp thread for processing. At some point Emacs must decide that
the popup menu is gone and let the gui thread update the screen. Why can
not this happen before processing the command choosen?
_______________________________________________
emacs-pretest-bug mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
