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#31920: 26.1; frame appears in wrong part of desktop after restoring frameset from fullscreen Date: Fri, 22 Jun 2018 14:17:52 +0200 Message-ID: <5B2CE8F0.8070702@gmx.at> References: <5B2B50C8.2090600@gmx.at> <87zhzo3083.fsf@gmail.com> <5B2CB996.4060606@gmx.at> <877emr2hmf.fsf@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1529669829 21301 195.159.176.226 (22 Jun 2018 12:17:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 22 Jun 2018 12:17:09 +0000 (UTC) Cc: 31920@debbugs.gnu.org, Jonathan Kyle Mitchell To: Robert Pluim Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jun 22 14:17:04 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 1fWKzw-0005Sc-Eo for geb-bug-gnu-emacs@m.gmane.org; Fri, 22 Jun 2018 14:17:04 +0200 Original-Received: from localhost ([::1]:33398 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fWL23-0007cs-KL for geb-bug-gnu-emacs@m.gmane.org; Fri, 22 Jun 2018 08:19:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41689) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fWL1t-0007bt-CZ for bug-gnu-emacs@gnu.org; Fri, 22 Jun 2018 08:19:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fWL1q-0007P7-69 for bug-gnu-emacs@gnu.org; Fri, 22 Jun 2018 08:19:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:51832) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fWL1q-0007Ot-1i for bug-gnu-emacs@gnu.org; Fri, 22 Jun 2018 08:19:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1fWL1p-0008Au-K7 for bug-gnu-emacs@gnu.org; Fri, 22 Jun 2018 08:19:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 22 Jun 2018 12:19:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 31920 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 31920-submit@debbugs.gnu.org id=B31920.152966988331346 (code B ref 31920); Fri, 22 Jun 2018 12:19:01 +0000 Original-Received: (at 31920) by debbugs.gnu.org; 22 Jun 2018 12:18:03 +0000 Original-Received: from localhost ([127.0.0.1]:59729 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fWL0s-00089W-SG for submit@debbugs.gnu.org; Fri, 22 Jun 2018 08:18:03 -0400 Original-Received: from mout.gmx.net ([212.227.17.22]:41767) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fWL0q-000891-Jc for 31920@debbugs.gnu.org; Fri, 22 Jun 2018 08:18:01 -0400 Original-Received: from [192.168.1.101] ([213.162.73.105]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MK0bZ-1fVWCK1wTV-001UZv; Fri, 22 Jun 2018 14:17:53 +0200 In-Reply-To: <877emr2hmf.fsf@gmail.com> X-Provags-ID: V03:K1:eKNr9maAcMdugQXYCTqCWZ6U8h+kFjeT4DTgqHU25E8c2K4DX5w Yj3HhIKNIm2SToCdSiESaAp1GY1LA2jvHpE/elsB2bV1lLblM19qz+j+HAC0iq45+DfmgQY MxWQCNo5pP9EG4uL9NHZMgezpNF/Yb9irT1ncQpIhI8l5XsFZe19XebvOOejPg5Jxf2+1If xENp5gOMGDhMpqRpzsnOw== X-UI-Out-Filterresults: notjunk:1;V01:K0:0gIgwbWBRqc=:30un0jEqWWSYu7yp/P/lBb /GesE6Lp66hFnElXVtd2ZyU+wta7hZe7/H0MyMltImgdBUJrgMs6z91FwXKJ3gfPSCVao2SAq 1ALrIgE9MP310XYVW3DiJ0UJIN3dXu1lGzroTMEOpb0ogTZkVTWKNHDFJsARLn5RTqvnJcqw2 kYTkm7MS+C9lduWxnBgjBlNEkvdsTN/whV5huv3ZoWomY11YiPdymJrO/pkY85L3Mx9QMhEGp efmGyfZAProtC9ijAQxhkavQKeCxnOFBCQDZ+jC22s1hK2FC+tPmJSgdJw9UwByi74TMyQvib y9x6H5vlJfNyicJuR7iMj9Kdm1TLu4XcKlXallROqm2BgUgJA5ljLAIubi5ceuTklQojqRnX7 XgzJypt+6qXvCFMvmbh/lk1mZKfO/WX4vbGmOAOMe7e2bocLfJJEqgBv6rCTCqJTqwjpD7xy6 UEwQfgjstQa+Be0+YdmSVl7n/vD0VOYy8YPHeAQxTFBtIKNvQZu1tpAzYDFUDOKPCLmZPYupG ru17x8ZLQhRWqtBBv5FaDyM95wiW79hbX4gPzdlpZXHnRYZPZI/oBfQS3wPtQCuaOm69bukD2 RNxyoqOPe8UbonJUqQ/ptjS59virVJclreROd6D5jIZNGcmbhGw2IvLzNmKMJYRqnNOhAVYt8 qBh7Cnw9zRvTT2qzkKfJGFvVOXwRcHFDaKh7q+fDN67gz6ox70vW9Ai9ft6cDy7b5AETYNcse LGmEgbEIPGghPoMPsEKCQ0+jj091MJqzRss7a+2SD+h/5Hm8Qm37+gyo/extPSrnvdT8xOnQ 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:147736 Archived-At: >> IIUC C-x r f runs the command 'frameset-to-register' which stores a >> "framset" in a register. C-x r j runs the command 'jump-to-register'= >> which does _not_ restore a frame's state via 'frameset--restore-frame= ' >> but goes to 'set-frame-configuration' instead. Apparently, framesets= >> and frame configurations differ in a couple of minor aspects and the >> fullscreen state is one of them. > > They do, but when edebugging jump-to-register, I end up in this branch= > of the cond: > > ((registerv-p val) > (cl-assert (registerv-jump-func val) nil > "Don't know how to jump to register %s" > (single-key-description register)) > (funcall (registerv-jump-func val) (registerv-data val))) > > Which ends up calling frameset--restore-frame, so the problem is elsew= here. Aha. I have no idea how to debug these cl-forms so I usually end up in some sort of nirvana. On Windows I call WM_EMACS_SETWINDOWPOS (in my_set_window_pos) with x =3D 902, y =3D 18, cx =3D 0, cy =3D 0, and Windows gets back to me with a WM_MOVE for (0, 0) - the values offered by GetWindowRect being left =3D 0, top =3D 0, right =3D 680, bottom =3D 658 I have no idea what to learn from this: (902, 18) is the correct request and I see no intervening action from there until Windows returns (0, 0). > The code that causes the frame to be restored in the wrong place is > this: > > (modify-frame-parameters frame > (if (eq (frame-parameter frame 'fullscreen) fullscreen) > ;; Workaround for bug#14949 > (assq-delete-all 'fullscreen filtered-cfg) > filtered-cfg)) > > in framset--restore-frame, which means I=CA=BCm going to have to break= out > gdb and/or printf. And removing the special fullsreen handling doesn't change anything? Maybe we _should_ do something special when a fullscreen frame is restored to a non-fullscreen one. Basically, Emacs has been doing something inherently wrong all the time: It asks to resize a frame while that frame is in fullscreen (or maximized) state. The correct interpretation on behalf of the window manager would be to store the new sizes and apply them when the frame is returned to its normal (non-fullscreen/non-maximized) state, IMHO. For some reason, the approach chosen by Emacs has worked so I never tried to fiddle with it. But maybe it bites us this time. >(I=CA=BCm surprised Eli is seeing this on MS-Windows > though, I thought the low-level frame implementation was completely > separate) I see this on Windows too. Normally, buggy behavior consistent across platforms is an asset. For some reason, this doesn't apply here yet. martin