Re: No refresh of buffer before popup-menu

[Lennart Borgman (gmail)]

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?