[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: No refresh of buffer before popup-menu

From: Lennart Borgman (gmail)
Subject: Re: No refresh of buffer before popup-menu
Date: Thu, 22 Feb 2007 10:22:26 +0100
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20061207 Thunderbird/ Mnenhy/

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?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]