On Thu 2013.05.02 at 00:22 -0400, [email protected] wrote: Hi, First off, thanks for the detailed report!
> While using emacs org mode and entering a timestamp using [C-c !] the > emacs window would drop to the bottom of the X stacking order. This > command can be traced to the raise-frame function which sends a raise > window request to cwm. > > It happened consistently for me, but when I asked another user on > daemonforums to try it he found it only happened on his macppc and not > his i386 machine. Also, I had it go away briefly when I fumbled in > getting debugging information (unstripped but no -g or maybe a mix of > object files with -g and without, not sure now). I mention this in > case you don't see the problem yourself. There's an uninitialized auto > involved, which I believe to be the cause of the pseudo-intermittency. > > With debugging info I could step through > xevents.c::xev_handle_configurerequest > and see the following: > > 1. The call to XConfigureWindow reuses the value mask from the > incoming XConfigureReqestEvent. > 2. The value of that mask was 64. i.e. CWStackMode (defined as 1 << 6 in X.h) > 3. CWStackMode is not one of the bits looked for in the preceding > check masks and set corresponding wc field statements. > 4. Not involved in my scenario I don't think, but CWSibling is also missing. > 5. The XWindowChanges variable wc used for the XConfigureWindow call > happens to have the value 1 for its stack_mode field for me. 1 is > defined as Below in X.h. Above is 0. > > When I add checks for CWStackMode and CWSibling with appropriate sets > of the corresponding wc fields (excuse the pun) the problem seems > fixed. If it's on top it stays on top. If it's lower it raises. Unfortunately, I'm not able to replicate, nor I suppose understand, the current behavior wrt to the behavior with the patch applied - basically, there's no change in my tests. I could be missing your point... > A couple other things puzzled me in this function that don't affect me > and may not be important: > 1. wc.border_width will be set if the incoming event has CWBorderWidth > in it's value mask, but a few lines later that value will be overwritten with > cc->bwidth. > 2. In the else clause the CWStackMode of the value mask is cleared but > the wc.stack_mode field is set. Is this for documentation that the > window will be raised by other means when the window eventually gets mapped? Yeah, those's intentional - "calm wm" is supposed to keep things in a way that the user expects; is that always right? probably not, but keeps the behavior sane. That said, you're right that it makes no sense to grab it then throw it away... Again though, I don't believe our X event handling does everything right; something to review. > >How-To-Repeat: > 1. with cwm running start emacs and an xterm > 2. place the emacs window so it overlaps the xterm window > 3. in the scratch buffer evaluate the emacs lisp expression > (raise-frame) > 4. you may see the emacs window fall to the bottom. > > Or, if you don't want to run emacs, compile and run this > program (I wanted to eliminate emacs as a culprit at one > point). If you overlap another window with it and click on it > you may see it fall to the back, or something. Sorry, I'm not able to replicate the issue with this either. If there is a missing initialization (as you mentioned), that could be why, and I want to find that as well. The patch isn't wrong, it just doesn't seem to change things (yet). Cheers, Okan
