Re: address@hidden: Re: redisplay]

[Jan Djärv]

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.