From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?ISO-8859-1?Q?Jan_Dj=E4rv?= Newsgroups: gmane.emacs.devel Subject: Re: [Stephen.Berman@gmx.net: Re: redisplay] Date: Wed, 25 Apr 2007 10:47:15 +0200 Message-ID: <462F1593.6030601@swipnet.se> References: <87mz0z5dux.fsf@stupidchicken.com> <462D059B.7020001@swipnet.se> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1177490920 15246 80.91.229.12 (25 Apr 2007 08:48:40 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 25 Apr 2007 08:48:40 +0000 (UTC) Cc: Chong Yidong , emacs-devel@gnu.org, Stefan Monnier , rms@gnu.org To: Glenn Morris Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Apr 25 10:48:31 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1HgdAt-0003Hb-9o for ged-emacs-devel@m.gmane.org; Wed, 25 Apr 2007 10:48:31 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HgdGU-0000jT-CH for ged-emacs-devel@m.gmane.org; Wed, 25 Apr 2007 04:54:18 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HgdGO-0000iM-R8 for emacs-devel@gnu.org; Wed, 25 Apr 2007 04:54:12 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HgdGM-0000fX-OF for emacs-devel@gnu.org; Wed, 25 Apr 2007 04:54:11 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HgdGL-0000f4-UY for emacs-devel@gnu.org; Wed, 25 Apr 2007 04:54:10 -0400 Original-Received: from av6-2-sn3.vrr.skanova.net ([81.228.9.180]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1HgdAh-0005se-8S; Wed, 25 Apr 2007 04:48:19 -0400 Original-Received: by av6-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 7E2B3380DB; Wed, 25 Apr 2007 10:48:17 +0200 (CEST) Original-Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av6-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 3584137F0C; Wed, 25 Apr 2007 10:48:17 +0200 (CEST) Original-Received: from husetbladh.homeip.net (81-235-205-78-no59.tbcn.telia.com [81.235.205.78]) by smtp3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id EEDBF37E44; Wed, 25 Apr 2007 10:48:15 +0200 (CEST) User-Agent: Thunderbird 1.5.0.10 (X11/20070221) In-Reply-To: X-detected-kernel: Linux 2.4-2.6 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:70079 Archived-At: Glenn Morris skrev: > Stefan Monnier wrote: > >> In any case, I have regularly seen similar problems when leaving >> Emacs: if I have processes running, Emacs displays a *processes* >> list, and because of my pop-up-frames (and/or >> special-display-regexps) settings, it does it by first popping up a >> new frame displaying this *processes* buffer, and then pops up a >> dialog asking me whether I really want to quit. The problem is that >> the *processes* frame is generally blank at that point. > > I've seen something which sounds like this as well. I see it > reproducibly with: > > emacs -Q > (setq special-display-regexps '(".*-diff\\*")) > (add-to-list 'minor-mode-map-alist > `(vc-mode keymap > (menu-bar keymap > (VC menu-item "VC" ,vc-menu-map)))) > > Then I visit a file under version control, make some changes, then > select VC->Revert to Base Version from the menu-bar. A frame with the > diffs gets popped up, as well as a dialogue box saying "Discard > Changes? Yes No". The diff frame is empty of mode-line and buffer > contents. > Thanks, now I see it. There is a race in here. I can see that redisplay on the new frame have not happened before the dialog pops up. When the dialog is up, redisplay is inhibited in xdisp.c, redisplay_internal. Sometimes the frame will get redisplayed properly, only to be cleared almost at once by an Expose event. This expose event happens in the middle of an ongoing redisplay, so a new redisplay is not started. Directly when the ongoing redisplay has finished, the dialog is popped up, and no redisplay is made. There are several possible solutions to this. 1. SYNC_INPUT. That way we won't get expose events in the middle of an ongoing redisplay. 2. Restart redisplay if an redisplay-related event arrives in the middle of an ongoing redisplay. 3. Use double buffering. That would get rid of the clearing of the frame. Unfortunately I don't see a quick fix for 22.1. Jan D.