From: Rolf Ade <rolf@pointsman.de>
To: martin rudalics <rudalics@gmx.at>
Cc: 31650@debbugs.gnu.org
Subject: bug#31650: 26.1; Desktop mode adds wm stickiness to emacs windows.
Date: Thu, 31 May 2018 15:00:41 +0200 [thread overview]
Message-ID: <87po1cdlom.fsf@pointsman.de> (raw)
In-Reply-To: <5B0FA40A.1060902@gmx.at> (martin rudalics's message of "Thu, 31 May 2018 09:28:10 +0200")
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
next prev parent reply other threads:[~2018-05-31 13:00 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-30 1:12 bug#31650: 26.1; Desktop mode adds wm stickiness to emacs windows Rolf Ade
2018-05-30 6:40 ` martin rudalics
2018-05-30 10:53 ` Rolf Ade
2018-05-30 12:37 ` martin rudalics
2018-05-30 14:49 ` Rolf Ade
2018-05-31 7:28 ` martin rudalics
2018-05-31 13:00 ` Rolf Ade [this message]
2018-05-31 13:55 ` martin rudalics
2018-05-31 14:05 ` Robert Pluim
2018-05-31 16:02 ` Robert Pluim
2018-06-01 6:09 ` martin rudalics
2018-06-01 6:41 ` Robert Pluim
2018-06-02 9:12 ` martin rudalics
2018-06-04 9:14 ` Robert Pluim
2018-05-31 22:58 ` Noam Postavsky
2018-06-01 6:09 ` martin rudalics
2018-06-01 10:47 ` Rolf Ade
2018-06-02 9:13 ` martin rudalics
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87po1cdlom.fsf@pointsman.de \
--to=rolf@pointsman.de \
--cc=31650@debbugs.gnu.org \
--cc=rudalics@gmx.at \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.