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: Mon, 28 Sep 2015 08:48:11 +0200 Message-ID: <5608E2AB.7010407@gmx.at> References: <55FFD141.2030405@gmx.at> <5600F763.3020305@gmx.at> <5601211E.3090001@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1443422961 15128 80.91.229.3 (28 Sep 2015 06:49:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 28 Sep 2015 06:49:21 +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 Mon Sep 28 08:49:11 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 1ZgSFK-0001FL-VA for geb-bug-gnu-emacs@m.gmane.org; Mon, 28 Sep 2015 08:49:11 +0200 Original-Received: from localhost ([::1]:60888 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZgSFK-0003rB-BY for geb-bug-gnu-emacs@m.gmane.org; Mon, 28 Sep 2015 02:49:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52778) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZgSFG-0003pR-58 for bug-gnu-emacs@gnu.org; Mon, 28 Sep 2015 02:49:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZgSFC-0005H0-Uv for bug-gnu-emacs@gnu.org; Mon, 28 Sep 2015 02:49:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:57155) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZgSFC-0005Gv-R7 for bug-gnu-emacs@gnu.org; Mon, 28 Sep 2015 02:49:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZgSFC-0007DU-JT for bug-gnu-emacs@gnu.org; Mon, 28 Sep 2015 02:49: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: Mon, 28 Sep 2015 06:49: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.144342290827697 (code B ref 21415); Mon, 28 Sep 2015 06:49:02 +0000 Original-Received: (at 21415) by debbugs.gnu.org; 28 Sep 2015 06:48:28 +0000 Original-Received: from localhost ([127.0.0.1]:46126 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZgSEd-0007Ca-9U for submit@debbugs.gnu.org; Mon, 28 Sep 2015 02:48:28 -0400 Original-Received: from mout.gmx.net ([212.227.17.20]:60924) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZgSEb-0007CN-1D for 21415@debbugs.gnu.org; Mon, 28 Sep 2015 02:48:25 -0400 Original-Received: from [188.22.234.5] ([188.22.234.5]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MY75A-1aBAOU1Zaq-00UsQR; Mon, 28 Sep 2015 08:48:14 +0200 In-Reply-To: X-Provags-ID: V03:K0:CWANeQzUc/FhRIQY0GT9wnY/gVhfjhriU6gQsRkqssSVKOVDX29 1WaN0ZMw4S00a/jd/4qBM6mNdvH8C0qV3/QCf0ugrZ3aE2UasAuuV4WsL2T0X7/smoKQV7Q +VxIO9APXBZpRjiegG9kQK7eZPbQL5ba+5LwWtWV/x4uwwBw3Jm1edhC8h9S46abda8qpXh YNP19kQrlx5Rnv2P9LkFg== X-UI-Out-Filterresults: notjunk:1;V01:K0:nLqiOd6vEEI=:K4zwLKzkfrJmZmIK42JVz8 TTt2/NOaPReCWxjzizSaz24HYbilG87azqYCcj4HZomQIe3l2JYWEN3Rn4shbYFP4AxD7bHbe 2IJRVJ0AjdTqByHAEgibDFuCCtsIJBS5N2ZT3RUfMAN8Lkecz2PX+OpVOnhLWBWBxoktqzk4e hG/vTZB4DWQYNbpjmzq2ZwXgIxfEv+ATcThI9UHotqaJkKNkRIGDaTiXzHn0WTynD+8QtTYKr Vh+F/Vxr5K//xS1OcqwiP+Etdl+0raAnXqJiXNPgyXkM4zfq+dS8WJEEHAZI7RhRlcSjFKrON yMNNZRNlBeEtvZ1zhNWue9NtYOPwuzM6SjZTguSyjsLIdL/oj5jJdjEX9zLxFbkkFS/V/yiEt ztk6u9lTXc6nDC/wO6Ep6awDfV5QTd3tvSJZw3DdhRmyxKdMEYXq+TnC2zVSjegLjG++XrgpP 0Pn9AwkZaERfO9sBA10v/+xW4K5zM8EUmMlmAGW83sFGuNzODvmIytNVc4wIGdWeT99CveMBH t2dQmRzQ5WMYcAUjrc5zQAREzyMdPqadY1OFbYqaH6ZugLmkzhvLG9EBTB/SP9mGmX5/bh9Wx e3+g11NBVHNdA9DYB3M67vS7YhuxiMi67fXH0OEj3q9uVIUqtYoGGCX1AgTg+dLtTz1ejqkAP L3odbGpgLQanfeOpedb766PWOh7DucsWwi1nO7bYtsiCn+pENm7xy+Z2i/RbELdsBPPz7qxgB lthhiDWHFLoyx8UCPTP+rOExxqyOqyCksC+RXw== 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:106988 Archived-At: > I found one problem related to `toggle-to-maximized'. If this happened= > right after `frame-resize-pixelwise' was set to a non-nil value, the > NSWindow parameter `resizeIncrement' must be updated. If this does not= > occur, the frame size is rounded down to only accommodate full charact= ers. > The extra space was distributed evenly above and below the frame. The > attached patch fixes this issue. Makes sense. Pushed as 73b0901..e55460e to master. > To see the difference, run Emacs -Q and evaluate the following. After = the > patch is applied, the frame is no longer moves down. > > (progn > (setq frame-resize-pixelwise t) > (toggle-frame-maximized)) > > Unfortunately, the frame still doesn't cover the entire screen. Usually it shouldn't, for maximizing. The problem as far as I understand is that NS doesn't have the concept of a "maximized" frame. > The > documentation to `windowWillUseStandardFrame' says: > > "The size of the current screen, which is the screen containing t= he > largest part of the window's current frame, possibly reduced on the to= p, > bottom, left, or right, depending on the current interface style." > > Effectively, this mean that the frame is reduced one pixel on the top = (if > the menu bar is visible) and four pixels at the bottom. This correspon= ds to > how other applications, like Chrome, works. When you do what, in Chrome? Try maximizing the Chrome window? How do you do that? > I think it would be relatively easy to override this (well, at least t= he > four pixels at the bottom), but I'm not sure if we should and, if so, = under > which conditions. (I can image that some users would like Emacs to fil= l the > entire screen whereas others might prefer the standard four pixels to = be > unused at the bottom.) We have the concept of a "workarea" as it's returned by =91display-monitor-attributes-list=92. On all systems I know of, a "maximized" frame occupies the full workarea, a "fullwidth" frame the full width of the workarea and a "fullheight" frame the full height of the workarea. (I have no idea how these concepts expand to multiple monitors though.) How do the four unused pixels relate to your workarea? > In the Info documentation to the `fullscreen' frame parameter, there a= re > two values missing: `nil' and `fullscreen'. The former indicates that = the > frame is in non-maximized state nil means "neither of =91maximized=92, =91fullwidth=92, =91fullheight=92 = or =91fullboth=92". > and the latter seems to behave like > `fullboth'. =91fullscreen=92 should not be used. I kept it in because I had the fain= t feeling that at some time it was used isntead of =91fullboth=92. > Interestingly, the function `toggle-frame-fullscreen' seems to > use this undocumented parameter value. It accepts it IIUC but it does not store it. Or what do you mean? Note that the documentations is still not very clear on the entire subject, mostly so because I don't know how other systems handle it. For example, xfce which I use on Debian seems to correctly cooperate with Emacs via the extended window manager hints with one exception: The state of the "resize" button in the title bar is the same for =91fullheight=92 and =91maximized=92. Consequently, using that button do= esn't quite DTRT for a full height frame. On Windows, Emacs controls =91fullheight=92 and =91fullwidth=92 and I see= no such problem. But you will nowhere find a description of the semantics of =91toggle-frame-maximized=92 when the frame is in the =91fullboth=92 s= tate and was =91maximized=92 before. Note also in this context that Stefan's bug #10670 "`fullscreen' frame parameter ill-named" is yet unresolved: The frame parameter `fullscreen' is ill-named: I think that it should = be renamed to `maximized' with accepted values nil, `vertical', `horizontal', `both', or `fullscreen'. I agree with his diagnosis but I disagree with the cure. And for compatibility reasons we would have to accept the old values anyway. > (In addition, there are some control > characters showing on the first line.) Please elaborate. > On a side note, the NSTRACE rewrite is coming along nicely (it really > helped in tracking down this problem) but it's not yet ready for relea= se. Fine. Can you please get yourself write access to the git repository so you can install it when it's ready? I feel some unease installing larger changes on systems where I cannot check the consequences myself immediately. martin