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: Tue, 03 Apr 2018 08:46:05 +0200 Message-ID: <5AC3232D.1020107@gmx.at> References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1522737914 21336 195.159.176.226 (3 Apr 2018 06:45:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 3 Apr 2018 06:45:14 +0000 (UTC) To: Drew Adams , 31031@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Apr 03 08:45: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 1f3Fgs-0005TA-5C for geb-bug-gnu-emacs@m.gmane.org; Tue, 03 Apr 2018 08:45:10 +0200 Original-Received: from localhost ([::1]:36798 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f3Fiv-0008G1-PQ for geb-bug-gnu-emacs@m.gmane.org; Tue, 03 Apr 2018 02:47:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33024) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f3Fil-0008Fc-Tc for bug-gnu-emacs@gnu.org; Tue, 03 Apr 2018 02:47:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f3Fig-0000T9-Tc for bug-gnu-emacs@gnu.org; Tue, 03 Apr 2018 02:47:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:56043) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1f3Fig-0000T5-Pg for bug-gnu-emacs@gnu.org; Tue, 03 Apr 2018 02:47:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1f3Fig-0005gY-I4 for bug-gnu-emacs@gnu.org; Tue, 03 Apr 2018 02:47: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: Tue, 03 Apr 2018 06:47: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.152273798821804 (code B ref 31031); Tue, 03 Apr 2018 06:47:02 +0000 Original-Received: (at 31031) by debbugs.gnu.org; 3 Apr 2018 06:46:28 +0000 Original-Received: from localhost ([127.0.0.1]:35707 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f3Fi7-0005fb-Tc for submit@debbugs.gnu.org; Tue, 03 Apr 2018 02:46:28 -0400 Original-Received: from mout.gmx.net ([212.227.15.19]:55465) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f3Fi3-0005fM-FS for 31031@debbugs.gnu.org; Tue, 03 Apr 2018 02:46:24 -0400 Original-Received: from [192.168.1.100] ([212.95.5.238]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0M5LJv-1eJZ2R4Aed-00zZsJ; Tue, 03 Apr 2018 08:46:13 +0200 In-Reply-To: X-Provags-ID: V03:K0:TVWzEikpnChSzveGO9KaG5+uScG5nDgzLBhz59MFQCnqkjMhgPj 6+0sEllrZSQ8pEd9ozrflFK3B+5mONUnKm3wk2lh8hBH10aNqbnoSS8hYTX2QwoYVgUMjSx J7p+KOZvBEa/2qsmra8uAi1BbPR3LIJw1Sz+12YQp8Oorh6qJE5744dtweHlbqW0oO3EiSE 4UKsCarFngkxZHG41i3Eg== X-UI-Out-Filterresults: notjunk:1;V01:K0:ED3p5CJ8fwc=:AZERY3FMPeL8IkQu2sGY/a q6eJyfNQNPC5TOed+rOrF7kxPq4t8zCTn4RUNLHuzPGd2RoCkNd53KNERM6KJ2KAQppAgflop A7lx17uMGSGQCphg9MZ0Vozjbj96MlINbAzuYsrN4fndxdJSkFu8c3vDhFaQQEhMjbKurbQH8 /2XQ4LfrMD1OGBoenQfWHuh7E4sIBajJ2DPTb2573jhAVjlaDjgoitf02OlGUl3PtdnO5Sn0t ZUSSMlimBfmlHi8J9rV4AxAFjw32qwqW+CET/KrdagiL9v/FLxQRBDuSj2HZ3HB3NpVvqldjU 1vuPSPlJp1pVyNI9eFgEJuv3P/4Fvilv2MCkijnUm+jyfg69pbpuRtCsKlk7J6czLderNBM0x iib5+I0kkZGWAZdATD9+pCFC7GuAc4s43DPMtoFQ+M7Lp2z0aQYPi8EBsJndGZj0mMJHqU6na 9OxuYsf4yyV+Yr9Wp72ixxa6QielqKgawQZjUiK4L/Iw+CDxlyKQoDefqe1bNusR+jQMlzHlp 7EszIoGkGZT4zuB6arnLtMWmyer0haRYXysM3yLzxwjiG+o6zdzfnu5Eeo6RekVFESrW7UWHj 7F8Sq8ErwXL4KkdoCbWGaafpCgfVbl3DqeecSNBOW+HKO1kSKzSLo97HyPDEqqkc2NdkSFwJ8 pj4RwzsZbbQcBcK1WeJGgeNtNdz1zdF+dBpOKCj1JIQrS6zRH2Muzcjp76RH1STOB0GoQ1QpE qhm5HK4Rb+6lgQP+AJkeqM/JMyIkt6Cdjj6/sMyCrUdWY2OXEySBNR80Lx6TSI2MrojlY4jX 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:144824 Archived-At: > Of course, the "out" is that it says, "In general, it is not a good idea > to position a frame relative to the right or bottom edge of its > display." But the only case discussed in that context is an initial/new > frame. It also talks about how these positions are stored and restored, for example, when saving the desktop. > And there is a similar caveat about using not using > floating-point with decorated frames. But again, it speaks only about > "when CREATING decorated frames. Because Emacs does not know the size of decorations _before_ a frame has been created. > The text talks about positioning flush to edges of the "display", which > I'm interpreting as the dominating monitor in the case of multiple > monitors. (Is that wrong?) I can't tell because I don't use multiple monitors and don't know what a dominating monitor is. Anyone who does - please compare behavior and manual with what she experiences in practical work and try to fix any errors she sees. > What I see is that the dominating monitor seems to have no effect, so I > wonder what "display" means here. > > And in fact using any of the following on an existing frame dominated by > the left monitor or the right monitor sends the frame to the _same_ > location: its left edge flush with the left edge of the right monitor: > > (modify-frame-parameters nil '((left . 0.0))) > (modify-frame-parameters nil '((left . - 0.0))) The last specification is wrong - floating point values must be unsigned. > (modify-frame-parameters nil '((left . 1.0))) On my single monitor display, evaluating the last form flushes the frame to the right of the display. If it doesn't on yours, then please try on a single monitor display first and then describe the observed misbehavior on your multiple monitor display. Maybe we can improve it, maybe we have to add a caveat to the manual. > (modify-frame-parameters nil '((left . - 1.0))) See above. > (And adding (user-position . t) changes nothing in this regard.) 'user-position' has no effect on Windows and can be silently ignored by window managers on GNU/Linux. Don't rely on it. > What am I misunderstanding, here? Can this text please be made more > clear? It's not really clear how floating-point values are supposed to > be used or what they are supposed to do. Dunno whether the behavior I'm > seeing is bugged or the doc is wrong or I'm misunderstanding it. Please state what you do not understand or can be improved in this text: A floating-point value in the range 0.0 to 1.0 specifies the left edge's offset via the "left position ratio" of the frame--the ratio of the left edge of its outer frame to the width of the frame's workarea (*note Multiple Terminals::) or its parent's native frame (*note Child Frames::) minus the width of the outer frame. Thus, a left position ratio of 0.0 flushes a frame to the left, a ratio of 0.5 centers it and a ratio of 1.0 flushes it to the right of its display or parent frame. Similarly, the "top position ratio" of a frame is the ratio of the frame's top position to the height of its workarea or parent frame minus the height of the frame. Emacs will try to keep the position ratios of a child frame unaltered if that frame has a non-`nil' `keep-ratio' parameter (*note Frame Interaction Parameters::) and its parent frame is resized. Since the outer size of a frame (*note Frame Geometry::) is usually unavailable before a frame has been made visible, it is generally not advisable to use floating-point values when creating decorated frames. Floating-point values are more suited for ensuring that an (undecorated) child frame is positioned nicely within the area of its parent frame. In particular, it states that specifying floating point values is more suited for child frames than for normal frames although by design they should work for the latter too. Thanks, martin