Re: No refresh of buffer before popup-menu

[Lennart Borgman (gmail)]

Eli Zaretskii wrote:
> > Date: Thu, 22 Feb 2007 00:35:07 +0100
> > From: "Lennart Borgman (gmail)" <address@hidden>
> > Cc: address@hidden
> >
> > 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?
>
> Because your model of what happens is incorrect.  The menu is
> processed in its entirety by the Windows menu-handling API, and Emacs
> never sees anything until the menu is popped down.
>
> IOW, we create the menu structure, call Windows, and then wait until
> the user chooses some menu item; only then does the Windows API return
> to Emacs with an indication of the user selection.  There's no queue
> in the Lisp thread where the menu-related events are put, because
> there are no events we see until the menu pops down.

So you mean that popup menus are not handled by the gui thread? Are they 
 handled like message boxes (by the desktop thread, or however it is 
done today)? Hm, yes, I vaugely remember that.

In that case I have even harder to see why the screen is not updated 
between the two popup-menu in the code I sent. Where is the output 
queued? Why? How can it be released?

It looks like sit-for believes it can not update the screen, but that 
seems to be a bug in this case. Or, is there some reason for this?