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:51:06 +0200 Message-ID: <5AC483EA.8020603@gmx.at> References: <5AC3232D.1020107@gmx.at> <0f7742b2-9e8e-47ed-a6c0-195e1985b5e0@default> 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 1522828217 23588 195.159.176.226 (4 Apr 2018 07:50:17 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 4 Apr 2018 07:50:17 +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 Wed Apr 04 09:50:12 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 1f3dBM-000613-AH for geb-bug-gnu-emacs@m.gmane.org; Wed, 04 Apr 2018 09:50:12 +0200 Original-Received: from localhost ([::1]:41116 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f3dDR-00044T-MA for geb-bug-gnu-emacs@m.gmane.org; Wed, 04 Apr 2018 03:52:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43955) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f3dDB-00041b-Ch for bug-gnu-emacs@gnu.org; Wed, 04 Apr 2018 03:52:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f3dD8-00087y-CM for bug-gnu-emacs@gnu.org; Wed, 04 Apr 2018 03:52:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:57909) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1f3dD8-00087r-8j for bug-gnu-emacs@gnu.org; Wed, 04 Apr 2018 03:52:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1f3dD8-00081n-2V for bug-gnu-emacs@gnu.org; Wed, 04 Apr 2018 03:52: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:52: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.152282828830821 (code B ref 31031); Wed, 04 Apr 2018 07:52:02 +0000 Original-Received: (at 31031) by debbugs.gnu.org; 4 Apr 2018 07:51:28 +0000 Original-Received: from localhost ([127.0.0.1]:37573 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f3dCa-000812-A4 for submit@debbugs.gnu.org; Wed, 04 Apr 2018 03:51:28 -0400 Original-Received: from mout.gmx.net ([212.227.17.21]:44381) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f3dCX-00080m-F7 for 31031@debbugs.gnu.org; Wed, 04 Apr 2018 03:51:25 -0400 Original-Received: from [192.168.1.100] ([212.95.5.201]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0M6SE3-1eKDDL0GJ1-00yTg4; Wed, 04 Apr 2018 09:51:16 +0200 In-Reply-To: <0f7742b2-9e8e-47ed-a6c0-195e1985b5e0@default> X-Provags-ID: V03:K0:R4YwqhFQqfR3Gn8q9/hJEpksl7Cxb+ju3wXY/7LdNzCBDiy9eG/ hlujxTUjpr61CRFW2Zu1t+n5kszHZLvPLXy4s3EYfUaqOjKDQTSQ8RzgrXA/MRbZFNomsu7 rZaxMf/eY+7UdV2J+Lk7Wh2dV9TiJUhVdTmLBLtluDDimC9eu8wXiJvbY9Ua2qsXHM0QZIm SJYZdwtBNH0VZngyGCgeA== X-UI-Out-Filterresults: notjunk:1;V01:K0:/slOcyRHXw8=:GdTu7KYH437cbzh/mJ0fet R3oM7XNjUEVb9OoNwoDVJLoyGU5KfISpoOauawgU+V4aHwYYuQoAgm67O/DUanfPRwnJzqzhC XyqiwuJaEF/ZnYW3eUo+ha2bcwgacqZoNjFkiLYQOXP5AE1sY+ZdHvKAuVNRWynOaDxWpPPKY cy8Hev0rxLgPVqRfY++qyzGpxK5W0SRVoBIS2RK1Q+5YaVZL1pKNO0HRgWLDw17jVgw49r63D 6pk/auR+xcsRYIFl8XoC0rI8kUi3FQwet0YWbFt7uQXHMhXgSV8bPLKt+DFGxap68oBuv/2iR JFc+s57HCX77toeLIqSuJgYblM6L/Di8ZIGXVl0BMrWvPpwIJdd72VUUM0KrpXeo+3C4r+Z6z ESRYCerCoCysTi00F0mHd2RlMbQbW7QuKWXM24JN7ZWmEECUY5YciszZo/BDqTFl9QA5Aaed6 FLFzssS2Xwu3qlK3ZeubYKsEh8Pzj4ruf6GTyZKrCqDq6h9ZMLcr/PeS7evugEhWJfxelYTrY JFDFhnqA2WS7IceqnDj516YvhMGO0hEt9+tEhns9VUAmcOr4pkpg8CHu9MNyDkEnm2um7nFaG ASI9W6rQVFfn/tQs12EBaeW28tXkY4GorhiET92O0UBGoMTkHa/u8cO4fvTg77Ie00zMzCGzq 8bSXxdod1uK9wAr8CmBKkg4DSLwdxaCEXTGsHwPiOJKsCzo7tnkX+r+1cG2C0XACvYfxy5s5a QPsXkiBmPhM6C0Zah3bmXqsz2LdRAWFIWUF6VjagJgxX11rwjAcnUuMbezVcDaS8gquoygy0 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:144876 Archived-At: > Yes. But I'm not sure why you mention that here. > What might I be missing? Because the desktop restore algorithm cannot restore the originally intended positioning, namely flushing the frame to the right whatever the size of the display is. > I have limited access to multiple monitors, myself. The > manual says that the monitor that dominates a frame is > "the monitor that contains the largest part of the window" > ((elisp) `Creating Frames'). And: > > A frame is =E2=80=9Cdominated=E2=80=9D by a physical monitor when e= ither the > largest area of the frame resides in that monitor, or (if the frame= > does not intersect any physical monitors) that monitor is the > closest to the frame. Every (non-tooltip) frame (whether visible > or not) in a graphical display is dominated by exactly one physical= > monitor at a time, though the frame can span multiple (or no) > physical monitors. -- (elisp) `Multiple Terminals' I read that text but since I have no experience with multiple monitors I have no idea of its practical implications. > With a single monitor it does indeed do what you say, and > what one would expect. When I tried with left and right > monitors I saw what I described (I don't have access to > multiple monitors today, but that is definitely what I > saw). Robert's experience seems to confirm yours. > I'm guessing now that `modify-frame-parameters' pays no > attention to the dominating monitor and expects its > position inputs to always use screen coordinates, i.e., > relative to all monitors combined, not relative to the > dominating monitor. Maybe. But then your problem should also show up when you try to position the left or top position of your frame by giving the offset of the left or top edge of the dominating monitor and that dominating monitor is not the left-/top-most one. Right? > If so then the doc about floating-point perhaps just needs > to be modified to not talk about "display" (which can be, > at least in some other places, the dominating monitor), > and instead talk about "screen" (which seems to always > refer to the space of all monitors taken together. Maybe, again. Is that display-screen dichotomy something we already document somewhere? If not we should fix the nomenclature first and I have no good idea how to do that (in Emacs sources you will still find places where the terms "frame" and "screen" are considered equivalents). So if there is some reasonable common understanding of this matter, we should specify what the terms "screen", "display", "monitor", "terminal" and "keyboard" stand for and how they relate to each other. > However, this part of the doc this report is about is > unclear in this regard: > > If you want to be sure the position you specify is not > ^^^^^^^^^^ > ignored, specify a non-=E2=80=98nil=E2=80=99 value for the =E2=80=98= user-position=E2=80=99 > parameter > > That suggests that here, at least, the parameter makes sure > that you get what you ask for. Ideally, yes. But all too often the window manager might want to correct that position to assure, for example, that a frame stays completely on-screen. > 1. Corrected wrt mention of "display", if it is in fact > the whole screen that is meant (e.g., in the case of > multiple monitors. I have to leave this part to someone who understands the implications of the use of multiple monitors. > 2. The text is pretty dense. This, in particular: > > A floating-point value ... specifies the > left edge=E2=80=99s offset via the =E2=80=9Cleft position ratio=E2= =80=9D of the > frame=E2=80=94the ratio of the left edge of its outer frame to th= e > width of the frame=E2=80=99s workarea (*note Multiple Terminals::= ) or > its parent=E2=80=99s native frame (*note Child Frames::) minus th= e > width of the outer frame. > > Maybe split that sentence into at least two sentences, but > probably three or four (or five). > > Maybe say "length of the left edge" instead of "left edge". These proposals are valuable. > What's the "outer frame" in the case of a non-child frame? The "outer frame" is described in section 29.3.1 Frame Layout. > Maybe say "screen area" instead of "frame's workarea"? The > latter is undefined, AFAIK, and can suggest the dominating > monitor and not the total screen area of all monitors. We want to position a frame within its workarea to avoid that the frame overlaps the windowing system's taskbar etc. > Maybe add "to" before "its parent's...", to make it more > clear that it's the ratio of the left-edge length to ___ > or ___ (minus...), not the ratio of the left-edge length > or ___ to ___ (minus...). But splitting the sentence up > into constituent pieces would help most. > > Maybe each term used should be defined here, rather than > sending readers elsewhere. If a reader has to go study > 4 other dense nodes to understand the terms used here in > a super-dense spec, then there are too many obstacles to > understanding. I understand your concerns but as you can see the "floating-point value" entry is already much larger than the remaining ones and since (if I understand Robert correctly) the "(- POS)" entry faces the same problems wrt multiple monitors, we have to sort out this more general problem anyway. In either case, reading the Frame Geometry section will remain a prerequsite for understanding some of the rest of the Frames chapter in the Elisp manual. martin