From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#31031: 27.0; (elisp) `Position Parameters', floating-point values Date: Tue, 3 Apr 2018 08:08:38 -0700 (PDT) Message-ID: <0f7742b2-9e8e-47ed-a6c0-195e1985b5e0@default> References: <5AC3232D.1020107@gmx.at> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1522768088 7687 195.159.176.226 (3 Apr 2018 15:08:08 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 3 Apr 2018 15:08:08 +0000 (UTC) To: martin rudalics , 31031@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Apr 03 17:08:04 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 1f3NXX-0001uC-Ey for geb-bug-gnu-emacs@m.gmane.org; Tue, 03 Apr 2018 17:08:03 +0200 Original-Received: from localhost ([::1]:41447 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f3NZb-0007jd-9a for geb-bug-gnu-emacs@m.gmane.org; Tue, 03 Apr 2018 11:10:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56250) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f3NYa-00072j-W0 for bug-gnu-emacs@gnu.org; Tue, 03 Apr 2018 11:09:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f3NYU-00058t-1A for bug-gnu-emacs@gnu.org; Tue, 03 Apr 2018 11:09:08 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:57566) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1f3NYT-00058h-SC for bug-gnu-emacs@gnu.org; Tue, 03 Apr 2018 11:09:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1f3NYT-0006l8-Kj for bug-gnu-emacs@gnu.org; Tue, 03 Apr 2018 11:09:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 03 Apr 2018 15:09:01 +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.152276813225961 (code B ref 31031); Tue, 03 Apr 2018 15:09:01 +0000 Original-Received: (at 31031) by debbugs.gnu.org; 3 Apr 2018 15:08:52 +0000 Original-Received: from localhost ([127.0.0.1]:37229 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f3NYI-0006kc-37 for submit@debbugs.gnu.org; Tue, 03 Apr 2018 11:08:51 -0400 Original-Received: from userp2120.oracle.com ([156.151.31.85]:36338) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f3NYF-0006kO-V7 for 31031@debbugs.gnu.org; Tue, 03 Apr 2018 11:08:48 -0400 Original-Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w33F49oG190105; Tue, 3 Apr 2018 15:08:42 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2017-10-26; bh=is6fJfxwTVF3F2eg/tTiRDv2sw4+fgdfm/kaLmDbbuc=; b=Q3XhFtcrSrOK8Wg5UirW0XqBbsYI76NKCHq4gAOFrj/D8Qni5f3L6R5KZqUfMcx9/zj+ MWpko0nQwzZH859iPRG3uTmAbXi6Ni9MSCaBxa6+/UNCUveHsIhFUIC9TM3vDCCPYW6z JR0J/p1/jQ7g6yLbp5xIWuXiZovzZynf9QFybR0bJup+DrraIXMi6rUTS97Bqf3Ktk4l uofddl9siJMVfEoGY7bg4QwoFxhCzHFPf6hS80g/RIGHnIPars1Kkk6HXQ2F+Qd6T9zE gOVDh1MxSjUZdH6J+jpSJuelZJWx5/6J7R0h1YU5RjNOo1JpMMqsMKnKQ7VQdqrC1saq Aw== Original-Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp2120.oracle.com with ESMTP id 2h4bx8r0v6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 03 Apr 2018 15:08:42 +0000 Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w33F8eZn012547 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 3 Apr 2018 15:08:41 GMT Original-Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w33F8ex9027129; Tue, 3 Apr 2018 15:08:40 GMT In-Reply-To: <5AC3232D.1020107@gmx.at> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4666.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8851 signatures=668697 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804030157 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:144854 Archived-At: > > Of course, the "out" is that it says, "In general, it is not a good id= ea > > 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/n= ew > > frame. >=20 > It also talks about how these positions are stored and restored, for > example, when saving the desktop. Yes. But I'm not sure why you mention that here. What might I be missing? > > 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. >=20 > Because Emacs does not know the size of decorations _before_ a frame > has been created. Yes. The case I'm asking about is the case of an existing frame. I don't expect any magic for the new-frame case. That part is clear enough, I think. > > The text talks about positioning flush to edges of the "display", whic= h > > I'm interpreting as the dominating monitor in the case of multiple > > monitors. (Is that wrong?) >=20 > 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. 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 either = 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' > > 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))) >=20 > The last specification is wrong - floating point values must be > unsigned. Ah yes. My bad. The doc does say 0.0 to 1.0. =20 > > (modify-frame-parameters nil '((left . 1.0))) >=20 > 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. 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). 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. 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. > > (And adding (user-position . t) changes nothing in this regard.) >=20 > 'user-position' has no effect on Windows and can be silently ignored > by window managers on GNU/Linux. Don't rely on it. OK. And the doc has generally made that clear. 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=98user-= position=E2=80=99 parameter That suggests that here, at least, the parameter makes sure that you get what you ask for. > > What am I misunderstanding, here? Can this text please be made more > > clear? It's not really clear how floating-point values are supposed t= o > > 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. >=20 > Please state what you do not understand or can be improved in this > text: [just a repeat of the existing doc] See what I've said already. I think it does not do what is described, for multiple monitors.=20 > 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. Yes, it says that. And yes, I am using "decorated" frames. But "they should work for the latter too" suggests that, well, they should work for the latter too. Don't get me wrong. I appreciate the care with which you wrote this doc (about floating-point values). I think perhaps it can be improved in two ways: 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. 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 the width of the frame=E2=80=99s workarea (*note Multiple Terminals::) or its parent=E2=80=99s native frame (*note Child Frames::) minus the 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". What's the "outer frame" in the case of a non-child frame? 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. 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. If you try to state the same info in multiple, very simple sentences, then I can try to make suggestions that might make that text flow better. But without that starting point of very simple statements I wouldn't really know where to start. (And probably the simple sentences would be fine as is, with no further suggestions needed.) HTH, and thanks for your work on this. I'm hoping that someone who has multiple monitors can chime in helpfully, as well. In sum, in priority, I'd suggest: 1. Possible code changes, to get the behavior consistent and understandable. 2. Factual changes to the doc to reflect that corrected behavior. 3. Simple sentences, defining terms (and possibly using diagrams) as needed, so the spec here is at least a bit more self-contained.