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 13:55:33 -0700 (PDT) Message-ID: <6336b8b4-49c0-4ce6-9044-cf558f12c16e@default> References: <<<<0bfd2e8d-9d9b-4737-a637-5175eaaf41c0@default> <57987CBA.2060405@gmx.at>>>> <<<<3657859c-03f1-4eca-9a78-a9be0dee6552@default>>>> <<<<83h9bbrqx5.fsf@gnu.org>>>> <<<06a3fb2a-b975-41cf-8aa3-c2cbe207057f@default>>> <<<838twnrngr.fsf@gnu.org>>> <<325b79e8-c40b-46f7-a89a-11f0888b0a68@default>> <<8360rqsy7i.fsf@gnu.org>> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1469652994 29383 80.91.229.3 (27 Jul 2016 20:56:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 27 Jul 2016 20:56:34 +0000 (UTC) Cc: 24085@debbugs.gnu.org To: Eli Zaretskii , Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jul 27 22:56:19 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 1bSVsH-0000Q9-V5 for geb-bug-gnu-emacs@m.gmane.org; Wed, 27 Jul 2016 22:56:18 +0200 Original-Received: from localhost ([::1]:48673 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bSVsD-00044M-PN for geb-bug-gnu-emacs@m.gmane.org; Wed, 27 Jul 2016 16:56:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33949) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bSVs7-00044G-0i for bug-gnu-emacs@gnu.org; Wed, 27 Jul 2016 16:56:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bSVs2-0008UU-OC for bug-gnu-emacs@gnu.org; Wed, 27 Jul 2016 16:56:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:51221) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bSVs2-0008UD-Jm for bug-gnu-emacs@gnu.org; Wed, 27 Jul 2016 16:56:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bSVs2-0002da-Df for bug-gnu-emacs@gnu.org; Wed, 27 Jul 2016 16:56: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 20:56: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.146965294710112 (code B ref 24085); Wed, 27 Jul 2016 20:56:02 +0000 Original-Received: (at 24085) by debbugs.gnu.org; 27 Jul 2016 20:55:47 +0000 Original-Received: from localhost ([127.0.0.1]:48518 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bSVrm-0002d2-J2 for submit@debbugs.gnu.org; Wed, 27 Jul 2016 16:55:46 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:40210) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bSVrk-0002cn-67 for 24085@debbugs.gnu.org; Wed, 27 Jul 2016 16:55:44 -0400 Original-Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u6RKtbEi008391 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 27 Jul 2016 20:55:37 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u6RKtapC024281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 27 Jul 2016 20:55:36 GMT Original-Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u6RKtZti007659; Wed, 27 Jul 2016 20:55:35 GMT In-Reply-To: <<8360rqsy7i.fsf@gnu.org>> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6744.5000 (x86)] X-Source-IP: userv0021.oracle.com [156.151.31.71] 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:121605 Archived-At: > > > Reverting the change will reintroduce the bug it fixed > > > > Obviously, as I indicated in my earlier message, I meant that the > > bug that it fixed should be fixed properly, without treading on > > `make-frame'. If on MS Windows you think the first Emacs frame > > should be positioned so that it does not overlap the task bar, > > then do that. But do it without affecting what `make-frame' does. > > > > > so doing that is out of the question. > > > > What _is_ in the question, then? >=20 > Anything else. Good! > > If you are unwilling to fix the code, will you fix the doc? >=20 > If that's the best we can do, yes. Also good - better than nothing. > > Just what bug did this change seek to fix? Wasn't it only the default, > > initial behavior of Emacs for the initial frame? If so, how is this > > general change to `make-frame' the right fix for that bug? >=20 > Please re-read the discussion, the answers are there. >=20 > > And how would it hurt for `make-frame' to at least respect an _explicit= _ > > frame alist argument, which is, after all, optional? Why does it have > > such an argument, if it no longer respects it? >=20 > The code that bothers you is not in make-frame. What bothers me is the effect on `make-frame', regardless of where the culprit code may be. > > But why take over the single, general-purpose frame-creation Lisp > > function we have, changing its behavior to ignore parts of optional > > arg PARAMETERS (on one platform, no less), just to accommodate the > > special case of the initial frame? >=20 > No one took over any Lisp function. The behavior of `make-frame' (this bug) was altered drastically, so that its optional PARAMETERS argument is at best problematic, and at worst nearly useless. The intention of the fix might not have been to do that, but that was the effect on `make-frame', which is what this bug report is about. > The code in question is deep in > the low-level support for creating frames on Windows. What it does is > make sure a frame, any frame, is not displayed with its echo area's > view obstructed by the task bar. That's a mistake (misguided), I think. Why was that the solution (or is the solution) to the problem reported, which was about the initial frame? As I said, it is entirely possible (and thank goodness) for either a user or Lisp code to _move_ a frame into positions that you want to avoid for the initial frame. Not just positions that don't show the echo area, but positions that can place any part - or all - of a frame off screen.=20 Can we not fix Emacs so that its avoidance of such positions is for the initial frame only? And if we can, let's please do that. The initial-frame case is a special (unique) case in this and other ways. Why should the behavior of a general function such as `make-frame' need to be sacrificed to fix that unique use case? And if there _were_ a good reason for `make-frame' to avoid such positions in a general, default case (which I would disagree with, FWIW), why would that be the case also for the non-default cases where you pass an explicit PARAMETERS list to `make-frame'? Surely, at least in that case the coder's intention should be respected. And a fortiori if (user-position . t) is in PARAMETERS. I cannot see any argument for _never_ being able to have `make-frame' respect PARAMETERS. I think (hope) you are saying that there is no good argument for not respecting PARAMETERS, but because of the previous, low-level fix, that's unfortunately where we are today. In that case, let's please try to do better. If `set-frame-parameter' can in a sense "override" or work around that low-level dictation of frame positioning, then I imagine it should be possible for `make-frame' to do the same. If nothing else, if PARAMETERS is present, shouldn't `make-frame' be able to at least update the frame parameters, respecting PARAMETERS, immediately after the low-level code creates it in the (wrong) position that it uses to avoid hiding the echo area? > > This makes no sense to me. And I find it hard to believe that you > > would not consider fixing that bug properly and restoring `make-frame' > > to a general-purpose function that respects whatever optional frame > > parameters are specified. >=20 > You put in my mouth things I didn't say. I'm glad to hear that, and I apologize if I misunderstood you. It must be said that you did not say much - hardly much to go on, to decipher your meaning or intention. Anyway, I take it now that you will seriously consider trying to fix this problem for `make-frame'? That would be great, and all that anyone could ask. I'll say again that this is not something that annoys me in my own use of Emacs, in general. I stumbled on it now, with emacs -Q, after it having been introduced 10 years ago apparently. But I think that Emacs's `make-frame' should behave as it did before, even if something should be done to ensure that the initial frame is not occluded. --- Since I have your attention, and if it doesn't take too much of your time, could you or Martin perhaps please recommend a way of getting the screen-relative pixel coordinates of a given buffer position in a given window of a given Emacs frame? I've been fiddling a bit with test code like this, but haven't really found anything reasonable yet: ;; Try to get screen-relative X, Y (pixels) for current point (let* ((posn-at-pt (posn-at-point)) (x-y (and posn-at-pt (posn-x-y posn-at-pt))) (win-edges (and x-y (window-inside-absolute-pixel-edges))) =09(x (and x-y (+ (car x-y) (car win-edges)))) =09(y (and x-y (+ (cdr x-y) (cadr win-edges)))) =09(y (and y (top-fudge-pixels y)))) ...) (defun top-fudge-pixels (y) (let ((y2 y)) (when tool-bar-mode (setq y2 (+ 40 tp))) (when menu-bar-mode (setq y2 (+ 25 tp))) (setq y2 (+ y2 28)) ; Frame title bar y2)) Just hoping I'm missing something simple, like a function `screen-relative-x-y-pixels-at-point'... Thanks, if you can point the way.