From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#24085: 25.1.50; `make-frame' given `top' param creates frame with ~10x smaller `top' Date: Wed, 27 Jul 2016 06:29:14 -0700 (PDT) Message-ID: <3657859c-03f1-4eca-9a78-a9be0dee6552@default> References: <0bfd2e8d-9d9b-4737-a637-5175eaaf41c0@default> <57987CBA.2060405@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1469626236 23224 80.91.229.3 (27 Jul 2016 13:30:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 27 Jul 2016 13:30:36 +0000 (UTC) To: martin rudalics , 24085@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jul 27 15:30:22 2016 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 1bSOui-0005Vw-Rb for geb-bug-gnu-emacs@m.gmane.org; Wed, 27 Jul 2016 15:30:21 +0200 Original-Received: from localhost ([::1]:46560 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bSOuh-0004o4-Vo for geb-bug-gnu-emacs@m.gmane.org; Wed, 27 Jul 2016 09:30:19 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40969) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bSOuW-0004j1-01 for bug-gnu-emacs@gnu.org; Wed, 27 Jul 2016 09:30:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bSOuR-0007cj-0W for bug-gnu-emacs@gnu.org; Wed, 27 Jul 2016 09:30:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:54717) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bSOuQ-0007cG-Tq for bug-gnu-emacs@gnu.org; Wed, 27 Jul 2016 09:30:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bSOuQ-0002oe-L2 for bug-gnu-emacs@gnu.org; Wed, 27 Jul 2016 09:30:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 27 Jul 2016 13:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24085 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 24085-submit@debbugs.gnu.org id=B24085.146962616910753 (code B ref 24085); Wed, 27 Jul 2016 13:30:02 +0000 Original-Received: (at 24085) by debbugs.gnu.org; 27 Jul 2016 13:29:29 +0000 Original-Received: from localhost ([127.0.0.1]:38821 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bSOtt-0002nN-FX for submit@debbugs.gnu.org; Wed, 27 Jul 2016 09:29:29 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:32632) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bSOtp-0002n7-SP for 24085@debbugs.gnu.org; Wed, 27 Jul 2016 09:29:26 -0400 Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u6RDTJ7P015618 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 27 Jul 2016 13:29:19 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u6RDTJQ0001920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 27 Jul 2016 13:29:19 GMT Original-Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u6RDTFBM030100; Wed, 27 Jul 2016 13:29:16 GMT In-Reply-To: <57987CBA.2060405@gmx.at> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6744.5000 (x86)] X-Source-IP: aserv0021.oracle.com [141.146.126.233] 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:121581 Archived-At: > Due to this change: > 2006-06-30 Ralf Angeli >=20 > =09* w32term.c (x_make_frame_visible): Use SystemParametersInfo with > =09SPI_GETWORKAREA to find the dimensions of the screen work area, > =09and adjust vertical position of the frame in order to avoid being > =09covered by the taskbar. >=20 > See the thread starting at > https://lists.gnu.org/archive/html/emacs-pretest-bug/2006-06/msg00142.htm= l > for the corresponding discussion. Wow. That's a revealing thread. Thanks for finding it. Such a large, and far-reaching (and bad) change resulting from so little discussion, by only two people, who were apparently only slightly annoyed by the _initial_ positioning of the initial (startup) frame. The thread is full of I-don't-know-whether-this-change-is-bad, I'm-not-sure-if-make-frame-is-the-right-place, maybe-we-should-not-do-this-if-top-is-explicitly-specified, etc. That should have been a sign that something might be misguided here. Would someone please revert this, and let `make-frame' respect the frame parameters handed to it, in particular `top'? I don't mind (I guess) if such fiddling is done only for the initial frame. The initial frame is anyway treated specially by Emacs. That would be the right place for this hack, if a place there must be. (But even for that I think that an explicit setting (e.g. in `initial-frame-alist') should be respected. And it does not make a lot of sense to assume that the task bar is in the default position, at the bottom of the screen.) But as I say, I don't mind if such fiddling is done only for the startup frame. It should not be done for other frames. `make-frame' is definitely the wrong place to do such fiddling. A user or code can (and should be able to) _move_ a frame to _any_ position, including partly or completely off screen. I see no reason why `make-frame' should not, likewise, respect `top', `left', etc. And especially when (user-position . t) is included! (It's not even clear (predictable?) exactly what fudging is done. You specify (top . 600) and you get something quite different and unpredictable.) Please, someone, reverse this (intentional) regression since Emacs 21. I haven't noticed it before because my own setup uses a standalone minibuffer and sets up other frames. I'm now testing some code with emacs -Q, and I am really surprised to see this behavior. This "fix" does not really address the problem (hiding part of the initial frame behind a Windows task bar) anyway, and it shoots Emacs in the foot in a general way (`make-frame' is a general, basic function). Pretty please, can we remove this ball-&-chain from `make-frame'? It should be a straightforward utility function, not some kind of mysterious DWIM djinn.