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#31031: 27.0; (elisp) `Position Parameters', floating-point values Date: Wed, 04 Apr 2018 09:49:26 +0200 Message-ID: <5AC48386.8040901@gmx.at> References: <5AC3232D.1020107@gmx.at> <874lksy9vy.fsf@gmail.com> <5AC35626.2070700@gmx.at> <877epowjq9.fsf@gmail.com> 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 1522828095 14692 195.159.176.226 (4 Apr 2018 07:48:15 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 4 Apr 2018 07:48:15 +0000 (UTC) Cc: 31031@debbugs.gnu.org To: Robert Pluim Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Apr 04 09:48:10 2018 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 1f3d9N-0003ih-Si for geb-bug-gnu-emacs@m.gmane.org; Wed, 04 Apr 2018 09:48:10 +0200 Original-Received: from localhost ([::1]:41015 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f3dBT-0003F8-6c for geb-bug-gnu-emacs@m.gmane.org; Wed, 04 Apr 2018 03:50:19 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42994) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f3dBH-0003AP-En for bug-gnu-emacs@gnu.org; Wed, 04 Apr 2018 03:50:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f3dBC-0006Ri-IU for bug-gnu-emacs@gnu.org; Wed, 04 Apr 2018 03:50:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:57901) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1f3dBC-0006Rd-DO for bug-gnu-emacs@gnu.org; Wed, 04 Apr 2018 03:50:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1f3dBC-0007yc-3U for bug-gnu-emacs@gnu.org; Wed, 04 Apr 2018 03:50: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: Wed, 04 Apr 2018 07:50:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 31031 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 31031-submit@debbugs.gnu.org id=B31031.152282818430633 (code B ref 31031); Wed, 04 Apr 2018 07:50:02 +0000 Original-Received: (at 31031) by debbugs.gnu.org; 4 Apr 2018 07:49:44 +0000 Original-Received: from localhost ([127.0.0.1]:37565 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f3dAu-0007y0-L7 for submit@debbugs.gnu.org; Wed, 04 Apr 2018 03:49:44 -0400 Original-Received: from mout.gmx.net ([212.227.17.21]:54093) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f3dAs-0007xm-9q for 31031@debbugs.gnu.org; Wed, 04 Apr 2018 03:49:42 -0400 Original-Received: from [192.168.1.100] ([212.95.5.201]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MZgdm-1enlHF3BLa-00LY9P; Wed, 04 Apr 2018 09:49:35 +0200 In-Reply-To: <877epowjq9.fsf@gmail.com> X-Provags-ID: V03:K1:QhyhRFIYVscxZlWJL2ZNLMG6QQzvg91yYue5gLCBU/LkD60pXao QfnyCTOxctgPYLugWj9XP8lxIRxKked30u0Usq7FVb7F/fJ9cfguRXW+6Su/RIMGpYQvfcW WZe8cX664KbxV4rAafk09fbuMJ4zCkog7mvmhLqc48wjtoogEaOs2tu2qO6TXAD+tCADVkj KflhpgP/Z4YgY9CseZhcw== X-UI-Out-Filterresults: notjunk:1;V01:K0:FYawkw2HHDk=:DWuuRI0ZxAoznWXG6jeaur d5Ay4tQjldkNYtS8Ftd/SqVt0f73GcM0FopxItEt088K4UcPLAJsGzvRxfTXgZCTCzO/WnJ17 HoKWE+31y4BrgMNpoj1wnelPen483cFGYyc0tkTA4CTugC36G2a+ia50jBgW8UH/AMynFM3lO v+QelORXY2QV8klkAmfKeWp5qBhujMv8EeyohQDA73IHZFWiyFl5yCwFEW5/S2wrElXX7mmUM Ax7dVNDUB6/Zb35Xd340kjxbgEqrIl3AthwmjZfILpf+joSXfogdRFyEc2KJivYiOo8lD26sU vfvg6GJNi4VZBFadjGDJHPPLIArbm+aCZd3961NuWbPPYgUvstiqOl17UzFB+V7gifnf+JI2L 0bDJSarBiNzsemJ8aZ+v3+qWfpZJE8bJAGZj6prn2W8c3XcC7b6eyQ8gVYL8zL55QIbOzBrme 1EWNpVFAUfiH+q1i+oU8i9OEbCnp0kyEsCv6WR22yCb8jLbwYe2Uw6fmPdlZ7nHkUbdKJIkzk kl4WkKC5NVh2XoFdXYdMRhtbNwmJ5u74959Yn54DH1tFuElIZbbbN3yMzY5itLB3n9gTBdo4+ 50wVhL/Q/ouDsvQB6Ypnr0ZhwdYhPX1YcoaXq5rFTOxOoFHKJIvUQBnF8wIV6RdjF1Oq6DiFc JkbHojHRz1RAbcWwPGREpg9RoB47gxDx6MYxbkhHBEYC77zdIQ6ypdYbb/LamxUpioWN5NHVJ e7GrNpuz0RqGl+ajpJ0cXl728tMWrtL61U+xRjWcmJm3igadfApXggtKBD/MLg1YwweyFI7h 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:144874 Archived-At: >> Can you try fixing that in some consistent manner? You can find the >> corresponding code in x_calc_absolute_position in xterm.c. BTW, does= >> it work right when you use the "(- POS)" specification? > > (modify-frame-parameters nil '((user-position . t) (left . (- 0)))) > > gives the same offset effect as > > (modify-frame-parameters nil '((user-position . t) (left . 1.0))) So we should try fixing (or documenting) the misbehavior of the (- n) notation first. > D'oh. Of course, top is the right parameter to use. With that the > frame switches monitor between top and bottom, so that would imply > that the same switching should happen for "left". I=CA=BCm undecided s= o far > as to which I think is the "correct" behaviour. I'm not sure I understand. Do you mean that when you change the value of 'left' the frame always stays within the left monitor while when you change 'top' the frame moves from the upper to the lower monitor and back? That would be queer. >>> [1] Not completely to the right, but that=CA=BCs a different issue >> >> Probably a problem with calculating the decorations. Does >> (frame-geometry) return "reasonable" values for your frame? > > (display-monitor-attributes-list) > (((name . "XWAYLAND0") (geometry 0 540 3840 2160) (workarea 0 540 3= 840 > 2094) (mm-size 350 190) (frames # rudalics* 0x3d5ce80> # #) > (source . "Gdk"))) > > (modify-frame-parameters nil '((user-position . t) (left . 1.0))) > > (frame-geometry) > ((outer-position 2340 . 1730) (outer-size 1480 . 824) Hmm ... 2340 + 1480 gives 3820 which is obviously 20 pixels to the left of 3840. This clearly went wrong. Did we _ask_ for 2340 or 2360? > (external-border-size 20 . 20) (outer-border-width . 0) > (title-bar-size 0 . 70) (menu-bar-external . t) (menu-bar-size 0 . = 0) > (tool-bar-external . t) (tool-bar-position . top) (tool-bar-size 0 > . 0) (internal-border-width . 0)) > > (+ 2340 1480) =3D> 3820, + external-border-size? In any case, visually= > the frame is not flush right. Do we anywhere add only one 'external-border-size' instead of two? > If I correct the visual aspect: > > (modify-frame-parameters nil '((left . (+ 2400)))) > > (frame-geometry) > ((outer-position 2380 . 1586) (outer-size 1480 . 824) > (external-border-size 20 . 20) (outer-border-width . 0) > (title-bar-size 0 . 70) (menu-bar-external . t) (menu-bar-size 0 . = 0) > (tool-bar-external . t) (tool-bar-position . top) (tool-bar-size 0 > . 0) (internal-border-width . 0)) > > which to me says there=CA=BCs a (-20) error for the outer-position at > least. Why did you ask for 2400 and not for 2360? If the position value is too large the window manager might try to fit the frame onto the screen. OTOH "correcting" this to 2380 means there are 20 pixels (the full right external border) missing on the right if not I am missing something. BTW is this on a high resolution display? Would/should we scale external borders on such a display too? martin > I=CA=BCll take a look at x_calc_absolute_position. Fine. Thanks, martin