GNU bug report logs - #31650
26.1; Desktop mode adds wm stickiness to emacs windows.

Previous Next

Full log

Message #17 received at 31650 <at> debbugs.gnu.org (full text, mbox):

From: Rolf Ade <rolf <at> pointsman.de>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 31650 <at> debbugs.gnu.org
Subject: Re: bug#31650: 26.1; Desktop mode adds wm stickiness to emacs windows.
Date: Wed, 30 May 2018 16:49:20 +0200

>> I start emacs -Q. The frame comes up and isn't sticky.
>>
>> Now I evaluate your code from above in the scratch buffer. It returns
>> nil. _But_: It also puts the frame into sticky mode!
>
> Does it also make the frame sticky when with emacs -Q you simply
> evaluate
>
>       (set-frame-parameter frame 'sticky nil)))

It's not exactly clear to me what code you ask me to evaluate (the code
above isn't syntactically correct or only a part of the code you want me
to evalute.

If I start emacs -Q and evalute just

(dolist (frame (frame-list))
  (set-frame-parameter frame 'sticky nil))

in the scratch buffer then, yes, this also puts the frame into sticky
mode.

> If so, then it would be helpful to debug x_set_sticky, set_wm_state,
> x_send_client_event and x_fill_property_data to know which value gets
> propagated there.  As it stands, it seems that we always turn on
> stickyness when setting this frame parameter to nil, so somehow the
> chain above seems to corrupt it.

Hm. From looking around I see that x_set_sticky and set_wm_state are C
functions in xterm.c and x_send_client_event and x_fill_property_data
are C functions in xselect.c.

I guess you mean I should run emacs under gdb, set breakpoints to that
functions and inspect the arguments given to the calls. Unfortunately
I'm not used to gdb.

With the help of etc/DEBUG (part of the emacs source distribution) I was
able to start emacs from within emacs with the help of M-x gdb, to set
break points to this four functions and run the new instance, with
execution stoping at my breakpoints.

But I'm unsure what information could help to understand the problem (I
guess, the values of the function parameters?) and how to gather them in
a way that provide insight.

I'd appreciate more detailed hints what (and how) I should look for.

Thanks,
rolf

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.