From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame Date: Tue, 22 Sep 2015 11:36:30 +0200 Message-ID: <5601211E.3090001@gmx.at> References: <55FFD141.2030405@gmx.at> <5600F763.3020305@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1442914646 31038 80.91.229.3 (22 Sep 2015 09:37:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 22 Sep 2015 09:37:26 +0000 (UTC) Cc: Keith David Bershatsky , 21415@debbugs.gnu.org To: Anders Lindgren Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Sep 22 11:37:15 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZeK0f-0001au-Ps for geb-bug-gnu-emacs@m.gmane.org; Tue, 22 Sep 2015 11:37:14 +0200 Original-Received: from localhost ([::1]:37954 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZeK0f-0006JB-4U for geb-bug-gnu-emacs@m.gmane.org; Tue, 22 Sep 2015 05:37:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45441) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZeK0a-0006Iu-1q for bug-gnu-emacs@gnu.org; Tue, 22 Sep 2015 05:37:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZeK0V-0005Ja-0s for bug-gnu-emacs@gnu.org; Tue, 22 Sep 2015 05:37:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:49042) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZeK0U-0005JV-UU for bug-gnu-emacs@gnu.org; Tue, 22 Sep 2015 05:37:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZeK0U-0001yx-QK for bug-gnu-emacs@gnu.org; Tue, 22 Sep 2015 05:37: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: Tue, 22 Sep 2015 09:37:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21415 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 21415-submit@debbugs.gnu.org id=B21415.14429146097558 (code B ref 21415); Tue, 22 Sep 2015 09:37:02 +0000 Original-Received: (at 21415) by debbugs.gnu.org; 22 Sep 2015 09:36:49 +0000 Original-Received: from localhost ([127.0.0.1]:41240 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZeK0G-0001xn-G5 for submit@debbugs.gnu.org; Tue, 22 Sep 2015 05:36:48 -0400 Original-Received: from mout.gmx.net ([212.227.17.22]:61912) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZeK0E-0001xb-5u for 21415@debbugs.gnu.org; Tue, 22 Sep 2015 05:36:46 -0400 Original-Received: from [194.166.83.143] ([194.166.83.143]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MKKaI-1Zfyh346Cc-001et5; Tue, 22 Sep 2015 11:36:36 +0200 In-Reply-To: X-Provags-ID: V03:K0:rRIOFOQr7P8goF2nW+p+75UURAiWZmU69x7tGowmnAlcTaO+BtL j7Zi1BLCbYzDgzdFKPZOkEW/abXiEzPUoO0xncUnKJdj8/L0Hf7C7iX38oTbdTevzdMLcpA CygeYflxgqldL7pbcUGzFNekZM1/8Qcmd9t+HXmrbnSbxilKX1ZMYrofdN2OIGYCkyIoz2p DxRi3iXGPlzmUuIO14c0Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:/XMT07th1Sw=:dZLhMI+16+F4NYsn85pwoO YdQSKqln39YAlp2iuwZueMWI98hEgg47JUauS5Ibt0lSS9+pnkdzjJHY2vFEzurV/1XTcfBlz E0VYXTtOXDc/kegVLsaPiYgqlPmr3KJtqbsvZOj1leUfmO5xfj8+JUQcxLki6JU9lsWE9QvMB nHdH+k5q/j8UDGAX9s/CxOjH6HtE8NZEZAxMTqgi1iOwTNM9h5xOm/HX7oz2nkVWKLy9O95u2 1E+SDDb2maX3vSBSvjiUaFvwcP/RK6IAuvPaUjhzd3INaZke4xVO/4C9eAK+TR9vjEWC0BJpp MpasS/OR6YC1qpPUTIfNFQxENUDAb/dq3CmHlR/L6eV7Wwzt0qypHhD3BKoGq6zrPH7lSPhVp IO5ff+MLdqay72J339CYDUQhqEiOsy6UmeEn8Qy1lco+m+DjiWvD+6uJoJx3TY4dKTUzrSuom b49iTE7L8BAF4OO5UGl3aWKGAKthlbteZL3dw5cBMsHBj/NoTlKGMw5NmHYb/uC5ZG7QsaxBn I8ScB4J8rB4PFkrRlc3JYClRSL02Ezpqd7f3buGYPX00pvTduG1sIfoaO93fU97O9u3QRU/xf uonp3CGVJMdn7+/sTxlqU2rzJfTJHHIW6PtLUTXDowGsDYP02bJtpqjmiXhqsh1e+/J2e16IQ d759IhsGABezL0ul03DjkYNmstgGuoWxR14w8XeXVDCqI5mkSNO7WmBdMUG/52I6CXY8XhD8U 5eFQabWwvD4xoA/bY33nr02XIMLEzOsA1C7nDA== X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x 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-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:106805 Archived-At: > I can take a look at it. However, the experience I had with the previo= us > bug was that it's immensely hard to follow what happens when it comes = to > frame resizing and placement. So what I will do is to first reimplemen= t the > NSTRACE package and then start looking for the problem. OK. As far as frame resizing is concerned I wrote some rudimentary Elisp support. Set the variable =E2=80=98frame-size-history=E2=80=99 to = a value like '(100) and you will get a (partly cryptic) list of requests to resize a frame and whether and how the request got honored. > By the way, is > there some kind of deadline coming up? Not for bugs like this. It's only short before a release that we only fix regressions introduced since the last release. > Also, things are starting to get so complicated so that we would need = to > state what each concept mean so that they can be implemented the same = way > on all systems. (When I wrote my "multicolumn" package I found tons an= d > tons of things that differed between systems, I just want to make sure= we > don't introduce more such things.) One thing that should work uniformly accross platforms is the =E2=80=98frame-geometry=E2=80=99 function as well as the recently introdu= ced =E2=80=98frame-edges=E2=80=99. Since I was never able to verify these fo= r OS X it would be a good start to make sure they deliver correct results there first. Done that, we should have a common platform to discuss the remaining issues. > In addition, we really must write test > cases automatically walking through all transitions, ensuring that not= hing > breaks in the future, One problem with automatic test cases is that numbers may lie about the effect you see on screen. For example, Emacs can resize your scroll bar width with completely correct metrics but since Gtk+ usually refuses to change scroll bar widths, the visual appearance is devastating. But obviously, automatic test cases would be very useful. > but also as this is a good way to describe the > intended behavior. Such description should be found in the frame geometry section of the Elisp manual. > I don't know what you mean by "fullboth", so I can't comment on what w= ould > happen when you collate "fullscreen" and "fullboth". "fullboth" is our misnomer for "maximized", that is, the frame should occupy the full work area of the display and its "maximize" button should indicate that the frame can be restored to its normal size (the latter implies that a maximized frame usually keeps its title bar). A "fullscreen" frame, OTOH, occupies the entire display area (including a task bar) and has no title bar. martin