From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Rolf Ade Newsgroups: gmane.emacs.bugs Subject: bug#31650: 26.1; Desktop mode adds wm stickiness to emacs windows. Date: Thu, 31 May 2018 15:00:41 +0200 Message-ID: <87po1cdlom.fsf@pointsman.de> References: <87zi0idk0c.fsf@pointsman.de> <5B0E4778.9030708@gmx.at> <87wovle7ow.fsf@pointsman.de> <5B0E9B14.4040707@gmx.at> <87tvqpdwr3.fsf@pointsman.de> <5B0FA40A.1060902@gmx.at> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1527771557 15643 195.159.176.226 (31 May 2018 12:59:17 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 31 May 2018 12:59:17 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) Cc: 31650@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu May 31 14:59:13 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 1fONAe-0003vs-I2 for geb-bug-gnu-emacs@m.gmane.org; Thu, 31 May 2018 14:59:12 +0200 Original-Received: from localhost ([::1]:43989 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fONCl-0001zY-81 for geb-bug-gnu-emacs@m.gmane.org; Thu, 31 May 2018 09:01:23 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48769) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fONCZ-0001yK-Oy for bug-gnu-emacs@gnu.org; Thu, 31 May 2018 09:01:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fONCR-0005nP-3q for bug-gnu-emacs@gnu.org; Thu, 31 May 2018 09:01:11 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:47806) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fONCQ-0005ms-VP for bug-gnu-emacs@gnu.org; Thu, 31 May 2018 09:01:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1fONCQ-0003Qt-Hn for bug-gnu-emacs@gnu.org; Thu, 31 May 2018 09:01:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Rolf Ade Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 31 May 2018 13:01: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.152777164513165 (code B ref 31650); Thu, 31 May 2018 13:01:02 +0000 Original-Received: (at 31650) by debbugs.gnu.org; 31 May 2018 13:00:45 +0000 Original-Received: from localhost ([127.0.0.1]:55703 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fONC9-0003QG-Dv for submit@debbugs.gnu.org; Thu, 31 May 2018 09:00:45 -0400 Original-Received: from mxout3.interscholz.de ([85.236.196.238]:34116) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fONC7-0003Q8-Ro for 31650@debbugs.gnu.org; Thu, 31 May 2018 09:00:44 -0400 Original-Received: from localhost (mxout3 [127.0.0.1]) by mxout3.interscholz.de (Postfix) with ESMTP id B15AB203F3; Thu, 31 May 2018 15:00:42 +0200 (CEST) X-Virus-Scanned: interscholz amavisd-new at mxout3.interscholz.de Original-Received: from server.web01.interscholz.net (server.web01.interscholz.net [85.236.196.138]) by mxout3.interscholz.de (Postfix) with ESMTP id 08BDF203A2; Thu, 31 May 2018 15:00:42 +0200 (CEST) Original-Received: from linux-qg7d (p5B31770D.dip0.t-ipconnect.de [91.49.119.13]) by server.web01.interscholz.net (Postfix) with ESMTPSA id 9A947340290; Thu, 31 May 2018 15:00:41 +0200 (CEST) In-Reply-To: <5B0FA40A.1060902@gmx.at> (martin rudalics's message of "Thu, 31 May 2018 09:28:10 +0200") 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:146774 Archived-At: martin rudalics 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