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#25943: 21.5 Frame Display Difficulties Date: Tue, 04 Apr 2017 09:25:47 +0200 Message-ID: <58E34A7B.70103@gmx.at> References: "<0b9853e8ecbdb18bb1b8c05347371a7e@127.0.0.1>" <58B925A4.4060406@gmx.at> "" <58BA900B.6040708@gmx.at> "<49adf8e1615512ac19189d75b5e04315@127.0.0.1>" <58BE8138.1040607@gmx.at> "<142b4d1d519a6bf87a5fe320d9eeb419@127.0.0.1>" <58C118CA.8020908@gmx.at> <2395d7c6fbe7358c894bc1406ffcbf45@127.0.0.1> <58C3CF94.3080604@gmx.at> <58D38075.2030409@gmx.at> <58DB63ED.8060305@gmx.at> <58DCB3DB.4050804@gmx.at> <18cc26f5bea50ebd503834074ebaa599@127.0.0.1> <58DF5892.3080001@gmx.at> <7ee8200b866d8067514fb8b0bb9e814b@127.0.0.1> <58E0AE5F.3070705@gmx.at> 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 1491290841 32093 195.159.176.226 (4 Apr 2017 07:27:21 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 4 Apr 2017 07:27:21 +0000 (UTC) Cc: "25943@debbugs.gnu.org" <25943@debbugs.gnu.org> To: david@ngdr.net Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Apr 04 09:27:16 2017 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 1cvIru-0007NI-CO for geb-bug-gnu-emacs@m.gmane.org; Tue, 04 Apr 2017 09:27:10 +0200 Original-Received: from localhost ([::1]:34305 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cvIs0-0001Zf-CG for geb-bug-gnu-emacs@m.gmane.org; Tue, 04 Apr 2017 03:27:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39139) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cvIrr-0001ZP-Ow for bug-gnu-emacs@gnu.org; Tue, 04 Apr 2017 03:27:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cvIrn-0004EP-PL for bug-gnu-emacs@gnu.org; Tue, 04 Apr 2017 03:27:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:33320) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cvIrn-0004EL-MO for bug-gnu-emacs@gnu.org; Tue, 04 Apr 2017 03:27:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cvIrn-00026N-5a for bug-gnu-emacs@gnu.org; Tue, 04 Apr 2017 03:27:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 04 Apr 2017 07:27:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25943 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 25943-submit@debbugs.gnu.org id=B25943.14912907717986 (code B ref 25943); Tue, 04 Apr 2017 07:27:02 +0000 Original-Received: (at 25943) by debbugs.gnu.org; 4 Apr 2017 07:26:11 +0000 Original-Received: from localhost ([127.0.0.1]:59746 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cvIqv-00024f-Ic for submit@debbugs.gnu.org; Tue, 04 Apr 2017 03:26:10 -0400 Original-Received: from mout.gmx.net ([212.227.15.15]:50827) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cvIqt-000248-BB for 25943@debbugs.gnu.org; Tue, 04 Apr 2017 03:26:08 -0400 Original-Received: from [192.168.1.100] ([213.162.68.81]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LrvWY-1byYN03lss-013fP6; Tue, 04 Apr 2017 09:25:57 +0200 In-Reply-To: X-Provags-ID: V03:K0:aphJ/gTEuI0ms7y2gazKaTPcub6JPjd/uIEJPkpGDKW/enMxMU5 WJ6owc9VZh0Ug9f47qxmpO7htIsmNcam+hrv7Hf9begZvksUsNVdtXgmGECTJaOGqH0qt8/ rxeyGlorEXxEIIt/McMBNFZv0B+xRGiIfWCYUthWek94A4bsjVc5FsxjLefGYTA8S0gZaA3 SucXjhQiz1t+zYWjzuI3w== X-UI-Out-Filterresults: notjunk:1;V01:K0:AeoQcG9mKVk=:BlI2cGBQXlxBRcoy+pfz1m QZXZOeeMScTEVlhGnLU5VEu34wpSVXAr1c51YrZ8dJpqu64zSobMHiOV7EFEMtAkooRYaz7Nb 8uyE96MsQEkT2ulO5vE6lOeuPF67fMs9s63NUkSky4as6ecjuklpZOchuuK8Wr4kfCTc3UnS8 w+eHf977zpxld4Vr2tyTmwoPTIIbKh9kNp72csWtLTVfzXx1qyL3Ot85nTU8phkWRdVFITr0Y rjtkNGnCBHjBAjad/HVSWWHINGkLRrun8fNjltaO8+0kGaB6W89Ip4RwIFEthqP+d8MHT7tJ9 m7DNiTcP/wECP1JecI/X9ZQAbl4BttpZxJFALj0HO25j3yv/hdEjmXEVnfpQPOsivNrUw2Iqe h8WDC4FmHoGdSFUJZDzEELQ/FlXHTXxgUrQrsmXDIqxVSJpl850/jxh01BpgGQrO6hYVyX5CH HBMgV44mVNmapPBujpS+vt155wwtBKoP6n5sW/rnnjlvOZC+LKJjKhWj2titUzWu01oa2BPFP 2gnY7o3oJMiVjQdWHRAUfsMhplE7XWgKpq8qx/IBYGaAcm8Lvq3++aivWPduAFENlXZKQ7FXb JctjTV8mbKKFoJq4vg6L+2Mk8KPmM4MNVVqdFouK92Gzf3xPRIMsmQUD5J5lidU7WrKuXM6J0 p8aM6hQk8Xa8xgymB0/nze2KflcacfVSa8IqtMrhAumoOcNmOpzXudhboctZj3N++8A+peofb mhtAHNBcYCwGl1Z92Gym9vQX/Bh9ZVeVMpEKz5W8qhkhY7uFWrelEjsZj6LZogMzx5tos/EE 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:131262 Archived-At: > (frame-edges frame 'outer=3Dedges) 'outer-edges please > (599 256 1431 940) (599 256 1431 940) (599 256 1431 940)) The first value looks wrong supposedly due to the outer=3Dedges mishap. > ;; Immediately after maximizing by clicking on the top-right +. Note = that > the value of frame is > ;; different. > frame > # That's normal. The notation is cryptic but people are fond of it. However, these values > (outer-size 2048 . > 1114) =2E.. > (0 100 2048 1151) (0 100 2048 1151) (0 100 2048 1151)) sampled from GTK clearly mismatch those of the Emacs window management routines > frame pixel: 832 x 684 cols/lines: 84 x 36 units: 10 x 19 > frame text pixel: 800 x 684 cols/lines: 80 x 36 and represent what you see on your images: A window manager window of 2048 x 1114 pixels and an embedded Emacs frame of 832 x 684 pixels. The size has not propagated properly. > ;; Just after obtaining the information above the (real, not reported)= > workarea expanded to its > ;; "proper" maximized size with no intentional input from me. I ran t= he > checks again, and the > ;; results are different. Now > (outer-size 2048 . > 1114) =2E.. > (0 100 2048 1151) (0 100 2048 1151) (0 100 2048 1151)) are as before but > frame pixel: 2048 x 1051 cols/lines: 205 x 55 units: 10 x 19 > frame text pixel: 2016 x 1051 cols/lines: 201 x 55 show that Emacs caught up with GTK. What happens when you click the =E2=80= =98+=E2=80=99 button three times in a row? BTW, I suppose that this behavior shows up only in your ssh setup and you cannot repeat it without tunneling. Do you observe a similar behavior via ssh when you substantially change the frame size via =E2=80=98set-frame-size=E2=80=99? Also, did you try the ssh experiment with your 23.2 build? And it would be interesting if you were able to reproduce the behavior with a 25.2 Luc= id or Motif build. > ;; I started a new emacs and ran (setq frame (make-frame '((tool-bar-l= ines > . 0))) ). Then I set the > ;; fullscreen parameter with results indicated below. > > (set-frame-parameter frame 'fullscreen 'maximized) > ;; The outersize changed to fullscreen, the (real) workarea did not ch= ange > in size, but it did > ;; relocate to Left Top. In other words the result was very similar t= o a > normal, problem, start. > > (set-frame-parameter frame 'fullscreen 'fullboth) > ;; From the position above, this caused the outerframe to increase in > size, eliminating the frame > ;; border. The workarea moved, further Left Top, but did not change i= n > size. With other words the behavior is the same regardless of whether you use `set-frame-parameter', M-F10 or the =E2=80=98+=E2=80=99 button on the tit= le bar. > (set-frame-parameter frame 'fullscreen 'fullheight) > (set-frame-parameter frame 'fullscreen 'fullwidth) > ;; I have never used these, so I do not know how they are intended to > work. After these, the shape > ;; changed to fullheight and fullwidth, respectively. The other dimen= sion > changed to the width and > ;; height of the workarea and the whole outershape moved so that it wa= s > centered horizontally and > ;; vertically respectively. The attached screenshot shows one of thes= e > configurations. I can't tell about these because you haven't included the =E2=80=98frame-geometry=E2=80=99 output but I suppose they won't tell us = anything new. Thanks, martin