From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#38452: 26.3; set-frame-position is slightly drifted Date: Tue, 3 Dec 2019 16:59:22 +0100 Message-ID: <4e51fee7-4c0d-aee8-57fc-6e6bff41fabb@gmx.at> References: <84r21nl8qq.fsf@PC-1S0-327.i-did-not-set--mail-host-address--so-tickle-me> <405761c5-6101-5efe-9b6b-66fcab8680da@gmx.at> <84h82iwio0.fsf@PC-1S0-327.i-did-not-set--mail-host-address--so-tickle-me> <94449a44-81df-1014-fb60-1ab4c4af0456@gmx.at> <84blspbiy0.fsf@PC-1S0-327.i-did-not-set--mail-host-address--so-tickle-me> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="130588"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 38452@debbugs.gnu.org To: Pascal Lambrechts Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Dec 03 17:17:52 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1icAs3-000Xra-CL for geb-bug-gnu-emacs@m.gmane.org; Tue, 03 Dec 2019 17:17:51 +0100 Original-Received: from localhost ([::1]:55682 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1icAs1-0004Vj-I8 for geb-bug-gnu-emacs@m.gmane.org; Tue, 03 Dec 2019 11:17:50 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60801) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1icAay-0004Ws-6I for bug-gnu-emacs@gnu.org; Tue, 03 Dec 2019 11:00:15 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1icAaq-0008I3-AD for bug-gnu-emacs@gnu.org; Tue, 03 Dec 2019 11:00:08 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:34970) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1icAap-0008Gf-TQ for bug-gnu-emacs@gnu.org; Tue, 03 Dec 2019 11:00:04 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1icAao-0007YO-RE for bug-gnu-emacs@gnu.org; Tue, 03 Dec 2019 11:00:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 03 Dec 2019 16:00:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38452 X-GNU-PR-Package: emacs Original-Received: via spool by 38452-submit@debbugs.gnu.org id=B38452.157538877828976 (code B ref 38452); Tue, 03 Dec 2019 16:00:02 +0000 Original-Received: (at 38452) by debbugs.gnu.org; 3 Dec 2019 15:59:38 +0000 Original-Received: from localhost ([127.0.0.1]:40943 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1icAaP-0007XH-T9 for submit@debbugs.gnu.org; Tue, 03 Dec 2019 10:59:38 -0500 Original-Received: from mout.gmx.net ([212.227.15.19]:37765) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1icAaM-0007Wz-KL for 38452@debbugs.gnu.org; Tue, 03 Dec 2019 10:59:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1575388764; bh=CeG0uepgu+tY/rwDaWu8bsgVQv5Iz275dhVt3FI++is=; h=X-UI-Sender-Class:Subject:To:References:Cc:From:Date:In-Reply-To; b=jC7V9WSWHM6ruaw84AVMJ9GxvX0+3euzs9k/+eUXgQkUrDl5jHTEVem6g936f43H9 4mXkFIXOFuHIXdzTRTvlnAUBq5Me7TXCb3IdUD5PHyKBhZJ8gs5EJfQy9K4/YBiJ5S yoZlnn3DNIGUp6U3h7qNe6J/bhPSl/MZnyTMDL7M= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.100] ([212.95.5.116]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MLi8g-1iKdhM1xtA-00HdZo; Tue, 03 Dec 2019 16:59:24 +0100 In-Reply-To: <84blspbiy0.fsf@PC-1S0-327.i-did-not-set--mail-host-address--so-tickle-me> Content-Language: de-AT X-Provags-ID: V03:K1:BRG5cXa/+qm/AQtb2ZivpHeNEeF37PPx1FXh0Egp8VYXY+pl4el s5uLi4tkDjLBdjAebvaiImbhHSR7hHS9pmTBEVhuviNlstuCwsUAYy7xKjfhn1oFX0BQh3e hhvCZR84pq09ArTkEHlV5f2e45NS7f9qUnKaqD7b/BB6FHjupJiCE6MqiFazxcvOn2mrBWr sB6X+rLRU5cJ89jQbCi+g== X-UI-Out-Filterresults: notjunk:1;V03:K0:K2wC2jo1JBU=:cp6AdrO4QZBDA/UTI/dMWr Z7zjLVp8gCz1YotggYzHdNR/8vcJhSBsHxq40NSSxXJM0uuGPKlY7gdsxf3XzQTH5Ch0zlzZR AzMQyPnFjct3IPcCZ03XcUgr03hTfQtDzPGMYo4borH+2svuG6YoAWa+NeHulDOMw7cYUgNwt uQGrgZpaw9skSmB4l02sGeV+AXUR56kM5GexnI2JHGOzDeXxUPGqsiGdKoUOTGXBeuyBEBSGc vlhfiTlcrTPOw0yrhtDkfAun+rL310Lw/fRf4Kq+lrbXu9RqwOQpW3V5kTqJvAhiJI+mrBY1m LxoxEcw5+4JigjZQ10GFkUYgwLaQLq4pk+ynwLLDrOIlJJbORQRtYkOO9CEqw+PHyQ95HvA4J Ymn1y6I+j6u3UOpby8j67aTOEUUnlMFH0I5v6NBQfT49t2M9f2V9A5Lo+f2kKYZKG9dLjP43P 8Yr/AYhzvBARSJe2ZP0stASeBbVJDEk/eM2F1hLYZ3IlgyePCpoNUMbrNiRrpGilKA+yU1m5X KQ4ehv0SrN9TyLhiPWl/OQjWCWXE4ntO1YPVDjZ8Uat8MPYebHoMkVTSyCvy9/GUQub4Yc4Fu I5EhGrn/wga1urdzJnNqJ9f5/2mGWC4FO/MXXbN+GTNO+vOmrMLyZOTT0l8dL+ceLFTno5Z/n /uvND0H+NMRLc0MCU2VdYOgF2/OdGavLPa6JrQnV2lxdM1+avYOEL0SPdM46DMQjiQf7OI42s UvBL7LeuaClJFNpR2IGgxbx4UUXsWQrktB+gjZNWcHalfg5V8fTQWKqsyPF95GPs2n6eklfW 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: 209.51.188.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:172812 Archived-At: > As you can read in this scratch the behaviour is even more mysterious > now. Indeed if I set the parameters and read them back by > frame-parameter both evaluated in a enclosing progn then I get the > expected values. But if I reread right after the parameters I get > different values !? My guess is that Emacs initially sets the parameter values to the requested values and asks the window manager to apply them and later sets the parameters to what the window manager has applied. If you retrieve their values in between these two steps, Emacs reports the requested and not the finally realized values. BTW, I still don't know what your window manager is. > pl-dock-left=E2=80=99s value is > (((name . "eDP-1") > (geometry 0 0 1920 1080) > (workarea 55 27 1865 1053) > (mm-size 309 174) > (frames # #) > (source . "Gdk"))) > > > pl-dock-bottom=E2=80=99s value is > (((name . "eDP-1") > (geometry 0 0 1920 1080) > (workarea 0 27 1920 1000) > (mm-size 309 174) > (frames # #) > (source . "Gdk"))) These values are consistent and make sense. > In the first configuration (my laptop screen as a unique scrren) it > seems that when the frame is at the top left corner the parameters > take values (L=3D45,T=3D19) (which probably correspond to the width of= the > dock and height of the menu line). Well 55 - 45 gives 10 and 27 - 19 gives 8, the values you reported in your original report as However the frame is slightly drifted by 10 pixel to the left and 8 pixels to the top. If we say that the origin for things to display on screen is (-10, -8) - something you could probably verify by moving the dock to the right and the menu bar line to the bottom - we have a clue. Just that it doesn't make sense to me, yet. > If I set-frame-position at (x,y) with 0<=3Dx<=3D55 and 0<=3Dy<=3D27 th= en the > frame does not move and the values are reset to (45,19). > If I set-frame-position at (60,30) then the frame moved a little bit a= nd > the parameters evaluate to (50,22). These fit into the picture sketched above. > Here is a scratch file on which I did some experiment commented. Fine exercise. Appreciated! > Th function pl-lt is defined to easily show the values of the paramete= rs > left/top of the frame: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D SCRACTCH INTERACTIVE LISP FILE WITH EXPERMINTS =3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > ;; This buffer is for text that is not saved, and for Lisp evaluation.= > ;; To create a file, visit it with and enter text in its buffer= =2E > > ;; Experiments with set-frame-position and the result values of the pa= rameters left and top of the frame > ;; Each parenthesis sexp has been evaluated with C-j =3D eval-print-la= st-sexp > (defun pl-lt () > "Returns a string giving the left/top positions of the current fram= e" > (concat " LEFT=3D" > (prin1-to-string (frame-parameter nil 'left)) > " TOP=3D" > (prin1-to-string (frame-parameter nil 'top)))) > > > ;; First experiments with the laptop as only display and the gnome-3 = dock on the left: > (display-monitor-attributes-list) > (((name . "eDP-1") (geometry 0 0 1920 1080) (workarea 55 27 1865 1053)= (mm-size 309 174) (frames # #) (source . "Gdk"))) > > > (set-frame-position nil 0 0) > t > ;; the frame is immediately below the menu line and on the immediate r= ight of the left dock > (pl-lt) > " LEFT=3D45 TOP=3D19" > (progn (set-frame-position nil 0 0) (pl-lt)) > " LEFT=3D0 TOP=3D0" > (pl-lt) > " LEFT=3D45 TOP=3D19" > (set-frame-position nil 45 19) > t > ;; this did not move the frame: still at left corner but not overlapin= g the dock or menu line > (pl-lt) > " LEFT=3D45 TOP=3D19" > (progn (set-frame-position nil 45 19) (pl-lt)) > " LEFT=3D45 TOP=3D19" > (pl-lt) > " LEFT=3D45 TOP=3D19" > (progn (set-frame-position nil 50 25) (pl-lt)) > " LEFT=3D50 TOP=3D25" > ;; this did not move the frame > (pl-lt) > " LEFT=3D45 TOP=3D19" > ;; the parameters changed between the (pl-lt) inside the progn and aft= er !!! Yes. This is what I mentioned at the top of this manual. > (progn (set-frame-position nil 55 27) (pl-lt)) > " LEFT=3D55 TOP=3D27" > ;; this did not move the frame > (pl-lt) > " LEFT=3D45 TOP=3D19" You didn't try (set-frame-position nil 56 28) here, it should move the frame to (46, 20) IIUC ;-) > (progn (set-frame-position nil 60 30) (pl-lt)) > " LEFT=3D60 TOP=3D30" > ;; this moved very slight the frame away from the left-top corner > (pl-lt) > " LEFT=3D50 TOP=3D22" > > > > (set-frame-position nil 400 100) > t > ;; this moved the frame sowewhere in the middle of the screen > (pl-lt) > " LEFT=3D390 TOP=3D92" > (progn (set-frame-position nil 390 92) (pl-lt)) > " LEFT=3D390 TOP=3D92" > ;; this moved a bit the frame towars the top left corner > (pl-lt) > " LEFT=3D380 TOP=3D84" > > ;; --------------------------- > ;; Second experiments with an external screen as single display > (display-monitor-attributes-list) > (((name . "DP-1-2") (geometry 0 0 1920 1080) (workarea 55 27 1865 1053= ) (mm-size 598 336) (frames # #) (source . "Gdk"))) > > (set-frame-position nil 0 0) > ;; the frame is immediately below the menu line and on the immediate r= ight of the left dock > t > (pl-lt) > " LEFT=3D45 TOP=3D19" > (progn (set-frame-position nil 0 0) (pl-lt)) > " LEFT=3D0 TOP=3D0" > (pl-lt) > > ;; Third experiment with a double display: internal display of laptop = + external display > ;; The external display is set as the 'primary' display and is suppose= d to be on the right > ;; of the laptop display. So the menu bar and dock are only on the ext= ernal display > (display-monitor-attributes-list) > (((name . "DP-1-2") (geometry 1920 0 1920 1080) (workarea 1920 27 1920= 1053) (mm-size 598 336) (frames # #) (source . "Gdk")) ((name . "eDP= -1") (geometry 0 0 1920 1080) (workarea 0 0 1920 1080) (mm-size 309 174) = (frames) (source . "Gdk"))) > (set-frame-position nil 0 0) > t > ;; the frame is now in the left-top corner of the laptoop screen (no m= enu neither dock here) > (pl-lt) > " LEFT=3D(+ -10) TOP=3D(+ -8)" > (progn (set-frame-position nil 0 0) (pl-lt)) > " LEFT=3D0 TOP=3D0" > (pl-lt) > " LEFT=3D(+ -10) TOP=3D(+ -8)" So here we see that a frame that should be located at (0, 0) is moved to (-10, -8). What does (modify-frame-parameters nil '((left . 0) (top . 0) (undecorated . t))) yield (to find out whether these 10/8 are due to the decorations)? > (progn (set-frame-position nil (+ -10) (+ -8)) (pl-lt)) The doc-string of 'set-frame-position' says that FRAME must be a live frame and defaults to the selected one. X and Y,= if positive, specify the coordinate of the left and top edge of FRAME'= s outer frame in pixels relative to an origin (0, 0) of FRAME's display.= If any of X or Y is negative, it specifies the coordinates of the righ= t or bottom edge of the outer frame of FRAME relative to the right or bottom edge of FRAME's display. so you tried to move the frame to some position near the bottom right corner of the display and these > " LEFT=3D2842 TOP=3D288" > ;; the previous evaluation has moved the frame on the external display= close to the right corner > (pl-lt) > " LEFT=3D2832 TOP=3D280" > (progn (set-frame-position nil 2832 280) (pl-lt)) > " LEFT=3D2832 TOP=3D280" > ;; the previous sexpevaluation has moved the frame slighly to the left= and top will be as expected provided the frame size and the LEFT/TOP values sum up accordingly. Does anything change in general when you explicitly request a position as with (modify-frame-parameters nil '((user-position . t) (left . 0) (top . 0)))= martin