bug#31650: 26.1; Desktop mode adds wm stickiness to emacs windows.

bug#31650: 26.1; Desktop mode adds wm stickiness to emacs windows.

[Rolf Ade]

I've

(desktop-save-mode 1)

in my init.el. This works fine for rare occasions is restart emacs.
Though, after restart, I not only find all my files open but the eamcs
window "sticky" speaking in windows manager terms, meaning if I jump to
another virtual desktop, my emacs windwos will "follow" me.

The emacs window wasn't in this state at the last
save-buffers-kill-terminal call. It doesn't have this state if I start
emacs -Q. It's  desktop-save-mode, that put my emacs window into this
state.

It's a minor nuisance, no doubt, but it's clearly wrong.

I'm using GNU Emacs 26.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 2.24.10) of 2018-05-29 built on linux-qg7d Repository revision:
 07f8f9bc5a51f5aa94eb099f3e15fbe0c20ea1ea Windowing system distributor
 'The X.Org Foundation', version 11.0.11203000 (x86_64) and as windows
 manager fvwm 2.6.

bug#31650: 26.1; Desktop mode adds wm stickiness to emacs windows.

[martin rudalics]

 > I've
 >
 > (desktop-save-mode 1)
 >
 > in my init.el. This works fine for rare occasions is restart emacs.
 > Though, after restart, I not only find all my files open but the eamcs
 > window "sticky" speaking in windows manager terms, meaning if I jump to
 > another virtual desktop, my emacs windwos will "follow" me.

We would eventually have to find out whether and how an Emacs frame
can get "spontaneously" sticky in a session that has not been polluted
from a saved desktop.  I'd suggest to proceed as follows: Somewhere
near the end of your init file (that is, after the code that restores
the previous desktop) insert this code:

(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)))

Now this should (1) make all your frames non-sticky in the new session
and (2) tell you if some frames were stored as sticky in your last
session.  If (2) happens frequently and you are sure that you have
never marked any frames as sticky, we could execute that code above
with an idle timer and so get an approximate indication of _when_ a
frame changes its stickyness spontaneously.

 > The emacs window wasn't in this state at the last
 > save-buffers-kill-terminal call.

How can you be sure of that?  The code for saving the desktop is dumb
and handles stickyness like any other frame parameter it does not
treat specially.  So it would surprise me if the desktop saving code
deliberately remembered a frame as sticky.

 > It doesn't have this state if I start
 > emacs -Q. It's  desktop-save-mode, that put my emacs window into this
 > state.
 >
 > It's a minor nuisance, no doubt, but it's clearly wrong.
 >
 > I'm using GNU Emacs 26.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 >   2.24.10) of 2018-05-29 built on linux-qg7d Repository revision:
 >   07f8f9bc5a51f5aa94eb099f3e15fbe0c20ea1ea Windowing system distributor
 >   'The X.Org Foundation', version 11.0.11203000 (x86_64) and as windows
 >   manager fvwm 2.6.

martin

bug#31650: 26.1; Desktop mode adds wm stickiness to emacs windows.

[Rolf Ade]

martin rudalics <rudalics@gmx.at> writes:
> We would eventually have to find out whether and how an Emacs frame
> can get "spontaneously" sticky in a session that has not been polluted
> from a saved desktop.  I'd suggest to proceed as follows: Somewhere
> near the end of your init file (that is, after the code that restores
> the previous desktop) insert this code:
>
> (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)))
>
> Now this should (1) make all your frames non-sticky in the new session
> and (2) tell you if some frames were stored as sticky in your last
> session.  If (2) happens frequently and you are sure that you have
> never marked any frames as sticky, we could execute that code above
> with an idle timer and so get an approximate indication of _when_ a
> frame changes its stickyness spontaneously.

Now, this is interesting.

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!

If I evaluate your code again, it now returns:

The following frames were found sticky: (#<frame emacs@linux-qg7d 0x131a320>)

But the emacs frame is still sticky. If I evaluate your code once again
(the third time) it returns nil, as the first time, but the frame is
still sticky.

If I "un-stick" the frame with the appropriate wm command and evaluate
your code again it returns nil, but puts the frame back into sticky
mode!

If I start emacs -Q and first put the frame into sticky mode (with wm
command) and then evaluate your code I get

The following frames were found sticky: (#<frame emacs@linux-qg7d 0x131a320>)

But the frame is still sticky. If I evaluate your code again it returns
nil, but the frame stays in sticky mode.

This seems weird but this is, what I see, reproducible. As written, this
is with emacs 26.1 and fvwm2 2.6.4

rolf

bug#31650: 26.1; Desktop mode adds wm stickiness to emacs windows.

[martin rudalics]

 > Now, this is interesting.

Unfortunately so.

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

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.

Thanks, martin

bug#31650: 26.1; Desktop mode adds wm stickiness to emacs windows.

[Rolf Ade]

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

bug#31650: 26.1; Desktop mode adds wm stickiness to emacs windows.

[martin rudalics]

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

bug#31650: 26.1; Desktop mode adds wm stickiness to emacs windows.

[Rolf Ade]

martin rudalics <rudalics@gmx.at> writes:
> 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

Yes, this avoids making the frame (I start with -Q) sticky.

> 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

Yes, this makes the frame sticky; I tried this already.

> (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?

Yes. This makes the frame sticky and doesn't change it afterwards.

> And I also suppose that
>
> (set-frame-parameter nil 'sticky t)
>
> behaves just the same as with nil.  Right?

Yes.

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

Yes, it does.

> while doing
>
> (set-frame-parameter nil 'sticky t)
>
> in the debugged emacs has
>
> p add
>
> print true instead.

Yes, it does.

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

Hopefully I've done this right ... If I did then: yes, I see the same.

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

Yes, it does. After starting emacs -Q (and frame is non-sticky)

(frame-parameter nil 'sticky)

returns nil. After I've made the frame sticky with wm command the same
code returns t. If I made un-sticky with wm command again it returns
nil.


Learned so far:

- It's not about desktop-mode, it's about set-frame-parameter, which
  doesn't seem to work correctly at least with some windows managers.

- Seems to be windows manager specific (you don't see it with xfwm4, I
  do with fvwm2 2.6.4).


I'll try to build fvwm2 2.6.7 (which seems to be the latest) and check
if it shows the same (mis-)behaviour. Though, that has to wait for
tomorrow.

If there is anything else I could to do help analyzing the problem just
let me know.

Thanks,
rolf

bug#31650: 26.1; Desktop mode adds wm stickiness to emacs windows.

[martin rudalics]

 > - It's not about desktop-mode, it's about set-frame-parameter, which
 >    doesn't seem to work correctly at least with some windows managers.

If worse comes to worst we can avoid setting the parameter when the
stored value alreay equals the requested value by writing something
like:

void
x_set_sticky (struct frame *f, Lisp_Object new_value, Lisp_Object old_value)
{
   Lisp_Object frame;
   struct x_display_info *dpyinfo = FRAME_DISPLAY_INFO (f);

   if (!EQ (new_value, old_value))
     {
       XSETFRAME (frame, f);

       set_wm_state (frame, !NILP (new_value),
		    dpyinfo->Xatom_net_wm_state_sticky, None);
     }
}

This might be even the right thing to do if, for example, the WM
decides that making a non-sticky frame non-sticky is a silly request
and the application probably wants a sticky frame instead.

 > - Seems to be windows manager specific (you don't see it with xfwm4, I
 >    do with fvwm2 2.6.4).

We would have to hear from others.  Anyone?  With emacs -Q evaluate

(set-frame-parameter nil 'sticky nil)

and look whether your frame starts to appear on all your desktops.

 > I'll try to build fvwm2 2.6.7 (which seems to be the latest) and check
 > if it shows the same (mis-)behaviour. Though, that has to wait for
 > tomorrow.
 >
 > If there is anything else I could to do help analyzing the problem just
 > let me know.

You have done a lot already.  But there are two things that might be
interesting to get the full picture: Put a brakpoint in xterm.c in
get_current_wm_state at the line

       else if (a == dpyinfo->Xatom_net_wm_state_sticky)

and look what value gets assigned here after you set stickyness on/off
via the window manager or via ‘set-frame-parameter’ - that means four
cases to check.

The second is to not use USE_XCB (_if you do_) by simply replacing
USE_XCB by 0 (zero) in all occurrences of this symbol in
get_current_wm_state - only if you can recompile, obviously.

I expect both of these not to change a thing in the actual behavior
since these are just the values reported to us by the WM but I'd like
to be sure that the WM behaves consistently in this regard.

And you could try to build Emacs without toolkit support (Lucid or
Motif would be better but may require to download some development
libraries) and look whether the problem persists.  Then we would know
that the problem is or is not toolkit dependent, where the former
would consitute a step forward.

Many thanks, martin

bug#31650: 26.1; Desktop mode adds wm stickiness to emacs windows.

[Robert Pluim]

martin rudalics <rudalics@gmx.at> writes:

> This might be even the right thing to do if, for example, the WM
> decides that making a non-sticky frame non-sticky is a silly request
> and the application probably wants a sticky frame instead.
>
>> - Seems to be windows manager specific (you don't see it with xfwm4, I
>>    do with fvwm2 2.6.4).
>
> We would have to hear from others.  Anyone?  With emacs -Q evaluate
>
> (set-frame-parameter nil 'sticky nil)
>
> and look whether your frame starts to appear on all your desktops.

That has no effect for me on Fedora 28 which I believe uses mutter as
the wm. Similarly running it multiple times has no effect.

Running

(set-frame-parameter nil 'sticky t)

once or multiple times results in a sticky frame, as expected.

Iʼll see if I can try on my KDE-based Ubuntu later. Thatʼs based more
directly on X, unlike my Fedora machine which is using XWayland.

Robert

bug#31650: 26.1; Desktop mode adds wm stickiness to emacs windows.

[Robert Pluim]

Robert Pluim <rpluim@gmail.com> writes:

> martin rudalics <rudalics@gmx.at> writes:
>
>> This might be even the right thing to do if, for example, the WM
>> decides that making a non-sticky frame non-sticky is a silly request
>> and the application probably wants a sticky frame instead.
>>
>>> - Seems to be windows manager specific (you don't see it with xfwm4, I
>>>    do with fvwm2 2.6.4).
>>
>> We would have to hear from others.  Anyone?  With emacs -Q evaluate
>>
>> (set-frame-parameter nil 'sticky nil)
>>
>> and look whether your frame starts to appear on all your desktops.
>
> That has no effect for me on Fedora 28 which I believe uses mutter as
> the wm. Similarly running it multiple times has no effect.
>
> Running
>
> (set-frame-parameter nil 'sticky t)
>
> once or multiple times results in a sticky frame, as expected.
>
> Iʼll see if I can try on my KDE-based Ubuntu later. Thatʼs based more
> directly on X, unlike my Fedora machine which is using XWayland.

And KDE seems to do absolutely nothing when we set or clear the sticky
parameter.

Robert

bug#31650: 26.1; Desktop mode adds wm stickiness to emacs windows.

[martin rudalics]

 > And KDE seems to do absolutely nothing when we set or clear the sticky
 > parameter.

Thanks for testing.  I'm not sure whether I understand this last
sentence: Does it mean that when you set to t the sticky parameter of
an unsticky frame, that frame does _not_ become sticky?

martin

bug#31650: 26.1; Desktop mode adds wm stickiness to emacs windows.

[Robert Pluim]

martin rudalics <rudalics@gmx.at> writes:

>> And KDE seems to do absolutely nothing when we set or clear the sticky
>> parameter.
>
> Thanks for testing.  I'm not sure whether I understand this last
> sentence: Does it mean that when you set to t the sticky parameter of
> an unsticky frame, that frame does _not_ become sticky?

Correct. KDE does support stickiness, but you have to interact with
some ridiculously complex picker that you get by right-clicking on the
window title bar. I donʼt know what that gets translated to at a lower
level.

I never want sticky windows, so itʼs not a big deal.

Robert

bug#31650: 26.1; Desktop mode adds wm stickiness to emacs windows.

[martin rudalics]

 > Correct. KDE does support stickiness, but you have to interact with
 > some ridiculously complex picker that you get by right-clicking on the
 > window title bar. I donʼt know what that gets translated to at a lower
 > level.

Funny.  With KWin, I suppose.

martin

bug#31650: 26.1; Desktop mode adds wm stickiness to emacs windows.

[Robert Pluim]

martin rudalics <rudalics@gmx.at> writes:

>> Correct. KDE does support stickiness, but you have to interact with
>> some ridiculously complex picker that you get by right-clicking on the
>> window title bar. I donʼt know what that gets translated to at a lower
>> level.
>
> Funny.  With KWin, I suppose.

Yes (not that I particularly worry about which window manager Iʼm
running as long as it does as itʼs told).

bug#31650: 26.1; Desktop mode adds wm stickiness to emacs windows.

[Noam Postavsky]

martin rudalics <rudalics@gmx.at> writes:

>> - Seems to be windows manager specific (you don't see it with xfwm4, I
>>    do with fvwm2 2.6.4).
>
> We would have to hear from others.  Anyone?  With emacs -Q evaluate
>
> (set-frame-parameter nil 'sticky nil)
>
> and look whether your frame starts to appear on all your desktops.

I tried with i3, seems to work correctly (all tests with a floating
window, since that seems to be a prerequisite for stickyness under i3):

(set-frame-parameter nil 'sticky nil) has no effect
(set-frame-parameter nil 'sticky t) makes the frame sticky,
and (set-frame-parameter nil 'sticky nil) makes it unsticky again.

I tested Emacs 26 with both Lucid and GTK builds.

bug#31650: 26.1; Desktop mode adds wm stickiness to emacs windows.

[martin rudalics]

 > I tried with i3, seems to work correctly (all tests with a floating
 > window, since that seems to be a prerequisite for stickyness under i3):
 >
 > (set-frame-parameter nil 'sticky nil) has no effect
 > (set-frame-parameter nil 'sticky t) makes the frame sticky,
 > and (set-frame-parameter nil 'sticky nil) makes it unsticky again.
 >
 > I tested Emacs 26 with both Lucid and GTK builds.

Thanks.  I suppose yours is the usual behavior since otherwise people
used to save and restore their desktops would have complained earlier.

martin

bug#31650: 26.1; Desktop mode adds wm stickiness to emacs windows.

[Rolf Ade]

Rolf Ade <rolf@pointsman.de> writes:
> [...]
> I'll try to build fvwm2 2.6.7 (which seems to be the latest) and check
> if it shows the same (mis-)behaviour. Though, that has to wait for
> tomorrow.

I build fvwm2 2.6.8 this morning, which was released 2 days ago and,
after some struggle, have this running now. And ... it doesn't has the
(mis-)behaviour of fvwm2 2.6.4.

With this version

(set-frame-parameter nil 'sticky nil)

has no effect on a non-sticky emacs.

(set-frame-parameter nil 'sticky t)

makes the frame sticky, and

(set-frame-parameter nil 'sticky nil)

makes it unsticky again.

As it should be. In turn emacs with enabled desktop-mode doesn't put my
emacs frame into sticky mode anymore at start-up. So, the root of the
reported problem seems to be a bug in some or at least one (2.6.4) past
fvwm2 version.

Case settled. Many thanks for replying and ...

I'm sorry for the noise ...

Thanks,
rolf

bug#31650: 26.1; Desktop mode adds wm stickiness to emacs windows.

[martin rudalics]

 > I build fvwm2 2.6.8 this morning, which was released 2 days ago and,
 > after some struggle, have this running now. And ... it doesn't has the
 > (mis-)behaviour of fvwm2 2.6.4.
 >
 > With this version
 >
 > (set-frame-parameter nil 'sticky nil)
 >
 > has no effect on a non-sticky emacs.
 >
 > (set-frame-parameter nil 'sticky t)
 >
 > makes the frame sticky, and
 >
 > (set-frame-parameter nil 'sticky nil)
 >
 > makes it unsticky again.
 >
 > As it should be. In turn emacs with enabled desktop-mode doesn't put my
 > emacs frame into sticky mode anymore at start-up. So, the root of the
 > reported problem seems to be a bug in some or at least one (2.6.4) past
 > fvwm2 version.

Great.  I added a corresponding entry for this to etc/PROBLEMS.

 > Case settled. Many thanks for replying and ...
 >
 > I'm sorry for the noise ...

On the contrary it's always good to inform about such misbehaviors.

Thanks, martin (closing this bug)