[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 00:35:07 +0100
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20061207 Thunderbird/ Mnenhy/

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?

reply via email to

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