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

Previous Next

Full log

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

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

>> 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.

Sorry.  I initially meant you to try with

(let (sticky-frames)
  (dolist (frame (frame-list))
    (when (frame-parameter frame 'sticky)
      (setq sticky-frames (cons frame sticky-frames))
      (set-frame-parameter frame 'sticky nil)))

  (when sticky-frames
    (message "The following frames were found sticky: %s" sticky-frames)))

which should _avoid_ making a frame inadvertently sticky during
checking but then I decided that it would be better to evaluate just

(set-frame-parameter nil 'sticky nil)

in order to _provoke_ making a frame sticky (this should explain where
the two extraneous right parentheses come from).  Evaluating the
latter does no change the stickyness of the emacs -Q frame here
(Debian with Xfce 4.8 and xfwm4).  Since with a single frame doing

> 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.

is equivalent to my single-line form you already confirmed that
setting the paramter to nil makes your frame sticky.  Hence our
systems apparently behave differently.  I suppose that evaluating

(set-frame-parameter nil 'sticky nil)

repeatedly makes your frame sticky the first time and does not change
("toggle") its stickyness afterwards.  Right?  And I also suppose that

(set-frame-parameter nil 'sticky t)

behaves just the same as with nil.  Right?

> 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.

Great.

> 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.

I'm unsure as well.  If I set a breakpoint in set_wm_state and
evaluate

(set-frame-parameter nil 'sticky nil)

in the debugged emacs, then doing

p add

in the debugging emacs prints false while doing

(set-frame-parameter nil 'sticky t)

in the debugged emacs has

p add

print true instead.  I suppose you see the same.  The next thing we
could check is whether setting a breakpoint at cons_to_x_long in
x_fill_property_data does produce a val of 0 for setting the parameter
to nil and 1 for setting the parameter to true (it does so here).

And one other thing to check is: When you set stickyness via the
window manager, does the 'sticky' parameter of your frame reflect the
actual state correctly?

martin

Previous Next

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