From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#31650: 26.1; Desktop mode adds wm stickiness to emacs windows. Date: Thu, 31 May 2018 09:28:10 +0200 Message-ID: <5B0FA40A.1060902@gmx.at> References: <87zi0idk0c.fsf@pointsman.de> <5B0E4778.9030708@gmx.at> <87wovle7ow.fsf@pointsman.de> <5B0E9B14.4040707@gmx.at> <87tvqpdwr3.fsf@pointsman.de> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1527751627 27391 195.159.176.226 (31 May 2018 07:27:07 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 31 May 2018 07:27:07 +0000 (UTC) Cc: 31650@debbugs.gnu.org To: Rolf Ade Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu May 31 09:27:03 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fOHzC-0006xc-Kx for geb-bug-gnu-emacs@m.gmane.org; Thu, 31 May 2018 09:27:02 +0200 Original-Received: from localhost ([::1]:42373 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fOI1I-0004W0-3f for geb-bug-gnu-emacs@m.gmane.org; Thu, 31 May 2018 03:29:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60184) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fOI1B-0004Vf-Pt for bug-gnu-emacs@gnu.org; Thu, 31 May 2018 03:29:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fOI18-0006tr-Mu for bug-gnu-emacs@gnu.org; Thu, 31 May 2018 03:29:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:47675) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fOI18-0006td-HY for bug-gnu-emacs@gnu.org; Thu, 31 May 2018 03:29:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1fOI18-0002b1-5T for bug-gnu-emacs@gnu.org; Thu, 31 May 2018 03:29:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 31 May 2018 07:29:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 31650 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 31650-submit@debbugs.gnu.org id=B31650.15277517099937 (code B ref 31650); Thu, 31 May 2018 07:29:02 +0000 Original-Received: (at 31650) by debbugs.gnu.org; 31 May 2018 07:28:29 +0000 Original-Received: from localhost ([127.0.0.1]:55571 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fOI0a-0002aD-P5 for submit@debbugs.gnu.org; Thu, 31 May 2018 03:28:29 -0400 Original-Received: from mout.gmx.net ([212.227.15.18]:33405) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fOI0Y-0002Zz-97 for 31650@debbugs.gnu.org; Thu, 31 May 2018 03:28:26 -0400 Original-Received: from [192.168.1.101] ([46.125.250.74]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MC4VE-1fX3Rr3F44-008pY3; Thu, 31 May 2018 09:28:19 +0200 In-Reply-To: <87tvqpdwr3.fsf@pointsman.de> X-Provags-ID: V03:K1:qOkVdJ1H9f8xEL9VEjJIFEuUlkA8Hi9J3lIJnyGY1TT5lAg6W8q IMgFPMz2+NwRwEvOHL37/hdDzYMK7jYu5dB6DedwhXFuAkhsJ+U/iSGw3UXhPdEPv6pu8sG eIbNyxdZcSRBQqylKw1Mktjb07M6OG8dmxINjRlmt52w+oDyJQ31G+hGDLs8iKN9OrthD0+ BLYiP+wLShDfiZ2qXhx2Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:SsdmNhG7PLs=:X5QGwJG6W+d3/Kv4hwIKAA XoFzB9in5kLXGTKGsMLT8Vdev45p5pAM/oifSsr8As2KkS9WR215mN+DZWdQV0fXfyt/42oQw /qGIJWdHC2N35cUXU269TUB5JQB/8EqI44MBzcE+LNZrQXHqVp9Jz6fLgkkweI3FZew/hmsf/ AhIUF4Uk5Z3Mh8k+TJ28TQOfaudEPyt038pIXx1wnvW/61YwAX9v2ftoJJpyKDyeGE8uSCG7q vx8nW7J/URGaE3MiItx1lCmUPrhw4puhvS2l44DMeRajb06oATGZ59flMkiDDWZpnYQEgjc/8 /tbPaCOo7+IY1zuCXdhDmssrZjy2cfcOTnt9S6pGAZcIHDBhfM4nESwAJUkEgKR3lGjP17Ta8 oI4+mSHufOdwaK5Eirfyi0P7RDoSO3Qc5dlCEwoeGypcP6aCyWXzGhXCYVdOnQTpYFFz1mB/v iCmxvxDtDP4Lc0LT11zTAexMwU1LfL1KrwDOldGIfXiWP8qPyhfPnPnWilEOtWwF61+1qB3Dn v7AdClLTw/bCaz7YU8tnVjHkyYKUhA2U5n5Ceif7WcNlkuANn+Qlh5lRDltXin2cnudvsXuGv 24Nh3ik7Ks0V5sCkqKJXqGiL3qsaVnkZia5s05gKAt2RSdM58KgVzXPq+8jNVxQ2TLdycy4O1 x7EIKVN5xr3FrL0gHCXM1EEF57yobpL8MgUZ5xZMv5+/18APqJJ/0igexwgEph+tXk3B08+0o kmjN15a0YfHtgFWCt2ffOsngy4TLwulwpW9kFrQM3GUXCHYRWWEklHwLwlp3TujgPVsbFKaG X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:146767 Archived-At: >> 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