From: martin rudalics <rudalics@gmx.at>
To: Rolf Ade <rolf@pointsman.de>
Cc: 31650@debbugs.gnu.org
Subject: bug#31650: 26.1; Desktop mode adds wm stickiness to emacs windows.
Date: Thu, 31 May 2018 09:28:10 +0200 [thread overview]
Message-ID: <5B0FA40A.1060902@gmx.at> (raw)
In-Reply-To: <87tvqpdwr3.fsf@pointsman.de>
>> 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
next prev parent reply other threads:[~2018-05-31 7:28 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 [this message]
2018-05-31 13:00 ` Rolf Ade
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=5B0FA40A.1060902@gmx.at \
--to=rudalics@gmx.at \
--cc=31650@debbugs.gnu.org \
--cc=rolf@pointsman.de \
/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.