GNU logs - #31031, boring messages

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#31031: 27.0; (elisp) `Position Parameters', floating-point values
Resent-From: Drew Adams <drew.adams@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 02 Apr 2018 21:57:02 +0000
Resent-Message-ID: <handler.31031.B.152270620925197 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 31031 <at> debbugs.gnu.org
MIME-Version: 1.0
Message-ID: <ea1a2a97-0ec3-47fb-8e74-2590e3a7fc89@default>
Date: Mon, 2 Apr 2018 14:56:28 -0700 (PDT)
From: Drew Adams <drew.adams@HIDDEN>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

I'm afraid this reads a bit like gobbledygook, to me.

And if I think I understand it, it doesn't seem to correspond to the
behavior I see.

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.  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

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?)

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)))
(modify-frame-parameters nil '((left .   1.0)))
(modify-frame-parameters nil '((left . - 1.0)))

(And adding (user-position . t) changes nothing in this regard.)

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.

In GNU Emacs 27.0.50 (build 3, x86_64-w64-mingw32)
 of 2018-03-21
Repository revision: e70d0c9e66d7a8609450b2889869d16aeb0363b5
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --without-dbus --host=3Dx86_64-w64-mingw32
 --without-compress-install -C 'CFLAGS=3D-O2 -static -g3''

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Drew Adams <drew.adams@HIDDEN>
Subject: bug#31031: Acknowledgement (27.0; (elisp) `Position Parameters',
 floating-point values)
Message-ID: <handler.31031.B.152270620925197.ack <at> debbugs.gnu.org>
References: <ea1a2a97-0ec3-47fb-8e74-2590e3a7fc89@default>
X-Gnu-PR-Message: ack 31031
X-Gnu-PR-Package: emacs
Reply-To: 31031 <at> debbugs.gnu.org
Date: Mon, 02 Apr 2018 21:57:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-gnu-emacs@HIDDEN

If you wish to submit further information on this problem, please
send it to 31031 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
31031: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D31031
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#31031: 27.0; (elisp) `Position Parameters', floating-point values
Resent-From: martin rudalics <rudalics@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 03 Apr 2018 06:47:02 +0000
Resent-Message-ID: <handler.31031.B31031.152273798821804 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Drew Adams <drew.adams@HIDDEN>, 31031 <at> debbugs.gnu.org
Message-ID: <5AC3232D.1020107@HIDDEN>
Date: Tue, 03 Apr 2018 08:46:05 +0200
From: martin rudalics <rudalics@HIDDEN>
MIME-Version: 1.0
References: <ea1a2a97-0ec3-47fb-8e74-2590e3a7fc89@default>
In-Reply-To: <ea1a2a97-0ec3-47fb-8e74-2590e3a7fc89@default>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

 > 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

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#31031: 27.0; (elisp) `Position Parameters', floating-point values
Resent-From: Robert Pluim <rpluim@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 03 Apr 2018 08:26:01 +0000
Resent-Message-ID: <handler.31031.B31031.152274393030586 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: martin rudalics <rudalics@HIDDEN>
Cc: Drew Adams <drew.adams@HIDDEN>, 31031 <at> debbugs.gnu.org
From: Robert Pluim <rpluim@HIDDEN>
References: <ea1a2a97-0ec3-47fb-8e74-2590e3a7fc89@default>
 <5AC3232D.1020107@HIDDEN>
Mail-Copies-To: never
Gmane-Reply-To-List: yes
Date: Tue, 03 Apr 2018 10:25:21 +0200
In-Reply-To: <5AC3232D.1020107@HIDDEN> (martin rudalics's message of "Tue, 03
 Apr 2018 08:46:05 +0200")
Message-ID: <874lksy9vy.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

martin rudalics <rudalics@HIDDEN> writes:

>> 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.
>

I see something similar using GTK on GNU/Linux, see below.

>> 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)))

I see the same: the frame always ends up flush left on the leftmost
monitor, regardless of whether it=CA=BCs initially displayed on the left or
right.

>> (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)))

This flushes almost [1] to the right when the frame is already
positioned on the rightmost monitor. When the frame is positioned on
the leftmost monitor, it ends up on the right edge of the left
monitor. Which monitor is primary doesn=CA=BCt matter, only the relative
positioning.

> 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.

I certainly find the current behaviour inconsistent: either the
repositioning should happen only within the workarea of each monitor,
or it should happen within the sum of the two workareas. What we have
now behaves differently depending on whether you flush left or flush
right.

Note that if I specify to my window manager that one of the monitors
is above the other rather than to the right, then the frame
repositioning always occurs within the confines of the monitor
displaying the frame.

Footnotes:
[1]  Not completely to the right, but that=CA=BCs a different issue

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#31031: 27.0; (elisp) `Position Parameters', floating-point values
Resent-From: martin rudalics <rudalics@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 03 Apr 2018 10:24:02 +0000
Resent-Message-ID: <handler.31031.B31031.15227510398755 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 31031
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Robert Pluim <rpluim@HIDDEN>
Cc: Drew Adams <drew.adams@HIDDEN>, 31031 <at> debbugs.gnu.org
Received: via spool by 31031-submit <at> debbugs.gnu.org id=B31031.15227510398755
          (code B ref 31031); Tue, 03 Apr 2018 10:24:02 +0000
Received: (at 31031) by debbugs.gnu.org; 3 Apr 2018 10:23:59 +0000
Received: from localhost ([127.0.0.1]:35866 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1f3J6d-0002H8-Cq
	for submit <at> debbugs.gnu.org; Tue, 03 Apr 2018 06:23:59 -0400
Received: from mout.gmx.net ([212.227.17.21]:35859)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rudalics@HIDDEN>) id 1f3J6c-0002Gs-2c
 for 31031 <at> debbugs.gnu.org; Tue, 03 Apr 2018 06:23:58 -0400
Received: from [192.168.1.100] ([213.162.73.239]) by mail.gmx.com (mrgmx101
 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MBrCt-1fCPVJ1fIl-00AmN7; Tue, 03
 Apr 2018 12:23:42 +0200
Message-ID: <5AC35626.2070700@HIDDEN>
Date: Tue, 03 Apr 2018 12:23:34 +0200
From: martin rudalics <rudalics@HIDDEN>
MIME-Version: 1.0
References: <ea1a2a97-0ec3-47fb-8e74-2590e3a7fc89@default>	<5AC3232D.1020107@HIDDEN>
 <874lksy9vy.fsf@HIDDEN>
In-Reply-To: <874lksy9vy.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K0:BTAwp5dpp2XtqFCcrA9ymvNoqzhL5zyshoR5yqwK0BcSicVeT9d
 xLcSgQwblbw0VQqLY1AmODAW++1Y8uAHPadbUE6yZU7r2b65Jk7witVKBWf9meoXNxDLFeX
 DrgPXIh97fJjTfLF5VNcEGSU2d43V4mnxUvNoiveFhwZ4yTHt1H++uaeTskm6jx95hShPog
 VuVgivqzVe+G/W8yIOqAw==
X-UI-Out-Filterresults: notjunk:1;V01:K0:HSeiHSioqpA=:FR1CFLi+TD2UffCECklbAp
 R91pNQE7kvhekauzFZoVaCmqgnict6sqq12kodVwiZLr3ang5qxEcCaWGIRmwDaqho+y8lyoa
 qXVOFX/2M9Y2yDvZ6VH51GzGyYSiSq8J/473/l7ZQpBOnPmw0oPdBGrlhWK8eJwNEah3GoNGS
 hOp3VrypHf86BYnUGq6LvwHkChFXajNNVXK5MYb9yy/oSvb9Gxc5L+oN1LEzSY/TB5TBnZj7B
 XS97z+nUdZzm9YLg5jFKjRNvuC4cFVhtwVbpAotTOWYwB4kzUVVdSfWesGADPyHe79o5bXzBU
 0BKXCUqcBu3xCsIcMyDtE2NvV0k2dIctu86fOPa8ATq+9xJvUHOFEbvrbgbmYjhyWyyfx11mX
 M9RylTLFwdS6duMg7YPXod/Ge1HIcpJJd+cTWl0JCThjteBfAytvE8WGQOpExdmmN0lGY26NV
 oAiskTym5WAFYKYFceL8l7VVT/ks8NZpIWAXqp8a0jxIyqHWzdQ3KMUkHT+p+0pbcQfH8snKF
 aKIId5aBMC/tYrPmXxX3aH60LgeZCee4bEzG0n2Er1e7yTJiFr44TjHhdDLmR4X2LwOB4um3M
 CpY2aaw/8oN2XNbRGqz3NHAcxpNHvS4glZChHjCkdYwRqfrJ8T4BRuQheJrB0RvzH0UfPiJio
 vblUu8k6hrIteQWqOnCPQzVU0GhM9Y3dM+r+g37ROCE5xc666n8j8Q1sJl2FwkhJSDtnZJzKX
 mPugD37Ksds1WiXNhOgUWx140UX4tMTVZ0Z5VySa4081+ir4IO17C8YJAtRbKJ4uQLCs+2JBH
 kYK3w5o8ZyNQxOebnvo5i0tBIbnZBriH1v4HNsqaDQgFXbm9Fm4PSRe6Sgscdks32jkqd15
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

 >>> (modify-frame-parameters nil '((left .   0.0)))
 >
 > I see the same: the frame always ends up flush left on the leftmost
 > monitor, regardless of whether it=CA=BCs initially displayed on the le=
ft or
 > right.

Thanks for testing.  I suppose that's the expected behavior.

 >>> (modify-frame-parameters nil '((left .   1.0)))
 >
 > This flushes almost [1] to the right when the frame is already
 > positioned on the rightmost monitor. When the frame is positioned on
 > the leftmost monitor, it ends up on the right edge of the left
 > monitor. Which monitor is primary doesn=CA=BCt matter, only the relati=
ve
 > positioning.

This sounds wrong.  I suppose the frame should move to the right edge
of the rightmost monitor.

 > I certainly find the current behaviour inconsistent: either the
 > repositioning should happen only within the workarea of each monitor,
 > or it should happen within the sum of the two workareas. What we have
 > now behaves differently depending on whether you flush left or flush
 > right.

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?

 > Note that if I specify to my window manager that one of the monitors
 > is above the other rather than to the right, then the frame
 > repositioning always occurs within the confines of the monitor
 > displaying the frame.

Did you try specifying the "top" parameter in that configuration?

 > [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?

martin

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#31031: 27.0; (elisp) `Position Parameters', floating-point values
Resent-From: Robert Pluim <rpluim@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 03 Apr 2018 12:36:02 +0000
Resent-Message-ID: <handler.31031.B31031.15227589523583 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 31031
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: martin rudalics <rudalics@HIDDEN>
Cc: 31031 <at> debbugs.gnu.org
Received: via spool by 31031-submit <at> debbugs.gnu.org id=B31031.15227589523583
          (code B ref 31031); Tue, 03 Apr 2018 12:36:02 +0000
Received: (at 31031) by debbugs.gnu.org; 3 Apr 2018 12:35:52 +0000
Received: from localhost ([127.0.0.1]:35985 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1f3LAG-0000vi-FM
	for submit <at> debbugs.gnu.org; Tue, 03 Apr 2018 08:35:52 -0400
Received: from mail-wm0-f41.google.com ([74.125.82.41]:38706)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rpluim@HIDDEN>) id 1f3LAE-0000vW-QM
 for 31031 <at> debbugs.gnu.org; Tue, 03 Apr 2018 08:35:51 -0400
Received: by mail-wm0-f41.google.com with SMTP id i3so11094579wmf.3
 for <31031 <at> debbugs.gnu.org>; Tue, 03 Apr 2018 05:35:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:references:mail-copies-to:gmane-reply-to-list
 :date:in-reply-to:message-id:mime-version:content-transfer-encoding;
 bh=WOpwq1cDAd2RdIWkZrWSwuba47OJCdsUKz5gcIbH/3M=;
 b=QoyTBfAv1dTiNuEdg9RFQjBO8UnBvUc18jBT5pb3czagYHDIDWEYC2ulricwlwEfWd
 0z91mDgpoZtWi1B0ZuU/rQTbzPHzyhZbuSjzFjqplUn83lcD6Nt3BgM0lZKLwN3UGWgn
 tgYK5tFO9sD9rqiPtV7yDrYu5gGiXeXdC6rJoZRg8gEEjRJDoMH12BnOG/AEA7kv1xrA
 TM95EjfboW8YQ9FUxTH91fgKA5OP6k+xH7uWN0jDOdPqZcmr8hTnhBcKxdGNwNQI8KQz
 nDhYR1aAytBAB+2xzyIF2m/w1jr/qTc0V1YZYRgnLKd3n+WQkBYI2I2msSZNmhmJIcTg
 pbtg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:references:mail-copies-to
 :gmane-reply-to-list:date:in-reply-to:message-id:mime-version
 :content-transfer-encoding;
 bh=WOpwq1cDAd2RdIWkZrWSwuba47OJCdsUKz5gcIbH/3M=;
 b=aC31NAwTBqDjKj1s13XRvNix2alQkeXuWaPrtOt9PC9GXaE+Dth3Fv9wpf+9Xk3kjt
 QbXN9+kCZwSS6+xmkD/D3T1K0ZKT/y0vg6hD4TGxKC1EBsObPHmf+8s6cr6wfdbi0Cm/
 3/HkvktMmI9Gzw5EuRyejQ5z61JKshBWWwTHc1ExICx8p4DyvZMJa8WVAmdWVhb0IoS1
 yjFZQqZofIS5nr2ZfJL+/gLYBiwTcZmYG9un9BYGGmy7yI1ImAjvWzKarOwsYrhIpAd8
 t59j0ujJoSEEZqho4YDhihtFonmrskRkTBYUxIjmzdl7ZmMz6SC6anS0lXnswmo6Rmbz
 IqBw==
X-Gm-Message-State: AElRT7EmurDzXT9b5bE1+lxszgCFb+7c161SPEe+NwE2RApb3x2XMB8i
 6+AdzKB105+hNqKm50yBtTQqvbHUQEk=
X-Google-Smtp-Source: AIpwx4/GKWU/OtIl0SyzUYnpNcyKbP/G+SCM6WfSPST4+/vY12sRLyU00zuhMOdpDaEzxblZnk7gqw==
X-Received: by 10.80.148.49 with SMTP id p46mr16305323eda.311.1522758944384;
 Tue, 03 Apr 2018 05:35:44 -0700 (PDT)
Received: from rpluim ([149.5.228.1])
 by smtp.gmail.com with ESMTPSA id n3sm1807708edl.27.2018.04.03.05.35.43
 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);
 Tue, 03 Apr 2018 05:35:43 -0700 (PDT)
From: Robert Pluim <rpluim@HIDDEN>
References: <ea1a2a97-0ec3-47fb-8e74-2590e3a7fc89@default>
 <5AC3232D.1020107@HIDDEN> <874lksy9vy.fsf@HIDDEN>
 <5AC35626.2070700@HIDDEN>
Mail-Copies-To: never
Gmane-Reply-To-List: yes
Date: Tue, 03 Apr 2018 14:35:42 +0200
In-Reply-To: <5AC35626.2070700@HIDDEN> (martin rudalics's message of "Tue, 03
 Apr 2018 12:23:34 +0200")
Message-ID: <877epowjq9.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)

martin rudalics <rudalics@HIDDEN> writes:

>>>> (modify-frame-parameters nil '((left .   0.0)))
>>
>> I see the same: the frame always ends up flush left on the leftmost
>> monitor, regardless of whether it=CA=BCs initially displayed on the left=
 or
>> right.
>
> Thanks for testing.  I suppose that's the expected behavior.
>
>>>> (modify-frame-parameters nil '((left .   1.0)))
>>
>> This flushes almost [1] to the right when the frame is already
>> positioned on the rightmost monitor. When the frame is positioned on
>> the leftmost monitor, it ends up on the right edge of the left
>> monitor. Which monitor is primary doesn=CA=BCt matter, only the relative
>> positioning.
>
> This sounds wrong.  I suppose the frame should move to the right edge
> of the rightmost monitor.

I=CA=BCm undecided on this now. See below.

>> I certainly find the current behaviour inconsistent: either the
>> repositioning should happen only within the workarea of each monitor,
>> or it should happen within the sum of the two workareas. What we have
>> now behaves differently depending on whether you flush left or flush
>> right.
>
> 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)))

>> Note that if I specify to my window manager that one of the monitors
>> is above the other rather than to the right, then the frame
>> repositioning always occurs within the confines of the monitor
>> displaying the frame.
>
> Did you try specifying the "top" parameter in that configuration?

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 so far
as to which I think is the "correct" behaviour.

>> [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 3840
  2094) (mm-size 350 190) (frames #<frame *unsent wide reply to martin
  rudalics* 0x3d5ce80> #<frame *info* 0x89f6ff0> #<frame *scratch* 0x87f1a0=
0>)
  (source . "Gdk")))

(modify-frame-parameters nil '((user-position . t) (left .  1.0)))

(frame-geometry)
  ((outer-position 2340 . 1730) (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))

(+ 2340 1480) =3D> 3820, + external-border-size? In any case, visually
the frame is not flush right. 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.

I=CA=BCll take a look at x_calc_absolute_position.

Robert

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#31031: 27.0; (elisp) `Position Parameters', floating-point values
Resent-From: Drew Adams <drew.adams@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 03 Apr 2018 15:09:01 +0000
Resent-Message-ID: <handler.31031.B31031.152276813225961 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 31031
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: martin rudalics <rudalics@HIDDEN>, 31031 <at> debbugs.gnu.org
Received: via spool by 31031-submit <at> debbugs.gnu.org id=B31031.152276813225961
          (code B ref 31031); Tue, 03 Apr 2018 15:09:01 +0000
Received: (at 31031) by debbugs.gnu.org; 3 Apr 2018 15:08:52 +0000
Received: from localhost ([127.0.0.1]:37229 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1f3NYI-0006kc-37
	for submit <at> debbugs.gnu.org; Tue, 03 Apr 2018 11:08:51 -0400
Received: from userp2120.oracle.com ([156.151.31.85]:36338)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <drew.adams@HIDDEN>) id 1f3NYF-0006kO-V7
 for 31031 <at> debbugs.gnu.org; Tue, 03 Apr 2018 11:08:48 -0400
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== 
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
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
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
MIME-Version: 1.0
Message-ID: <0f7742b2-9e8e-47ed-a6c0-195e1985b5e0@default>
Date: Tue, 3 Apr 2018 08:08:38 -0700 (PDT)
From: Drew Adams <drew.adams@HIDDEN>
References: <ea1a2a97-0ec3-47fb-8e74-2590e3a7fc89@default>
 <5AC3232D.1020107@HIDDEN>
In-Reply-To: <5AC3232D.1020107@HIDDEN>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1  (1003210) [OL
 16.0.4666.0 (x86)]
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
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-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)

>  > 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.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#31031: 27.0; (elisp) `Position Parameters', floating-point values
Resent-From: martin rudalics <rudalics@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 04 Apr 2018 07:50:02 +0000
Resent-Message-ID: <handler.31031.B31031.152282818430633 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 31031
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Robert Pluim <rpluim@HIDDEN>
Cc: 31031 <at> debbugs.gnu.org
Received: via spool by 31031-submit <at> debbugs.gnu.org id=B31031.152282818430633
          (code B ref 31031); Wed, 04 Apr 2018 07:50:02 +0000
Received: (at 31031) by debbugs.gnu.org; 4 Apr 2018 07:49:44 +0000
Received: from localhost ([127.0.0.1]:37565 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1f3dAu-0007y0-L7
	for submit <at> debbugs.gnu.org; Wed, 04 Apr 2018 03:49:44 -0400
Received: from mout.gmx.net ([212.227.17.21]:54093)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rudalics@HIDDEN>) id 1f3dAs-0007xm-9q
 for 31031 <at> debbugs.gnu.org; Wed, 04 Apr 2018 03:49:42 -0400
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
Message-ID: <5AC48386.8040901@HIDDEN>
Date: Wed, 04 Apr 2018 09:49:26 +0200
From: martin rudalics <rudalics@HIDDEN>
MIME-Version: 1.0
References: <ea1a2a97-0ec3-47fb-8e74-2590e3a7fc89@default>	<5AC3232D.1020107@HIDDEN>
 <874lksy9vy.fsf@HIDDEN>	<5AC35626.2070700@HIDDEN>
 <877epowjq9.fsf@HIDDEN>
In-Reply-To: <877epowjq9.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
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/MLg1YwweyFI7hF
 as1Nd0wXG9YkB4JSS7xyEVfM2fgdVKnwSBvkE6VyuRq28fOT3OHraJHzUHzLCEFBa6fb1YI
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

 >> 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 #<frame *unsent wide reply to marti=
n
 >    rudalics* 0x3d5ce80> #<frame *info* 0x89f6ff0> #<frame *scratch* 0x=
87f1a00>)
 >    (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

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#31031: 27.0; (elisp) `Position Parameters', floating-point values
Resent-From: martin rudalics <rudalics@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 04 Apr 2018 07:52:02 +0000
Resent-Message-ID: <handler.31031.B31031.152282828830821 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 31031
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Drew Adams <drew.adams@HIDDEN>, 31031 <at> debbugs.gnu.org
Received: via spool by 31031-submit <at> debbugs.gnu.org id=B31031.152282828830821
          (code B ref 31031); Wed, 04 Apr 2018 07:52:02 +0000
Received: (at 31031) by debbugs.gnu.org; 4 Apr 2018 07:51:28 +0000
Received: from localhost ([127.0.0.1]:37573 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1f3dCa-000812-A4
	for submit <at> debbugs.gnu.org; Wed, 04 Apr 2018 03:51:28 -0400
Received: from mout.gmx.net ([212.227.17.21]:44381)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rudalics@HIDDEN>) id 1f3dCX-00080m-F7
 for 31031 <at> debbugs.gnu.org; Wed, 04 Apr 2018 03:51:25 -0400
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
Message-ID: <5AC483EA.8020603@HIDDEN>
Date: Wed, 04 Apr 2018 09:51:06 +0200
From: martin rudalics <rudalics@HIDDEN>
MIME-Version: 1.0
References: <ea1a2a97-0ec3-47fb-8e74-2590e3a7fc89@default>
 <5AC3232D.1020107@HIDDEN> <0f7742b2-9e8e-47ed-a6c0-195e1985b5e0@default>
In-Reply-To: <0f7742b2-9e8e-47ed-a6c0-195e1985b5e0@default>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
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
 QPsXkiBmPhM6C0Zah3bmXqsz2LdRAWFIWUF6VjagJgxX11rwjAcnUuMbezVcDaS8gquoygy0x
 L9VDj5zjA55V5syL61Zl3O1xJSiqzN0EwsQQHQ9VTU1mDCj96ZqR6ggiaXcis08AZbAyu2B
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

 > 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

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#31031: 27.0; (elisp) `Position Parameters', floating-point values
In-Reply-To: <ea1a2a97-0ec3-47fb-8e74-2590e3a7fc89@default>
Resent-From: Robert Pluim <rpluim@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 04 Apr 2018 12:08:02 +0000
Resent-Message-ID: <handler.31031.B31031.152284367528967 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 31031
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: martin rudalics <rudalics@HIDDEN>
Cc: 31031 <at> debbugs.gnu.org
Received: via spool by 31031-submit <at> debbugs.gnu.org id=B31031.152284367528967
          (code B ref 31031); Wed, 04 Apr 2018 12:08:02 +0000
Received: (at 31031) by debbugs.gnu.org; 4 Apr 2018 12:07:55 +0000
Received: from localhost ([127.0.0.1]:37758 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1f3hCl-0007X8-0x
	for submit <at> debbugs.gnu.org; Wed, 04 Apr 2018 08:07:55 -0400
Received: from mail-wm0-f53.google.com ([74.125.82.53]:37323)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rpluim@HIDDEN>) id 1f3hCj-0007Ww-VJ
 for 31031 <at> debbugs.gnu.org; Wed, 04 Apr 2018 08:07:54 -0400
Received: by mail-wm0-f53.google.com with SMTP id r131so41808752wmb.2
 for <31031 <at> debbugs.gnu.org>; Wed, 04 Apr 2018 05:07:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:references:mail-copies-to:gmane-reply-to-list
 :date:message-id:mime-version:content-transfer-encoding;
 bh=rUfaZXjVcobo9lScNESuGkfZTvNpuqTtGvrdZSFo5kE=;
 b=Vc1mR7I+RwojgQ+PNLHuLQ+vZtArdurKMT11JOeNwfnsCQblfKawsacJd5JImujirl
 4tDOq9RKbJhO2t/aaznDqF8W8n7wHY4RnLfZU0z+aV5YM5kmrxsyymCGm3tKqf+CVNvX
 r0UdQVdDlXP6V2/IpJHRFMv7AqPfs/8HKpSZJs1GpxnnArVYyL9Zvn93BSx55n6Ijc/u
 ++NBpTmJnBPC+eQDqalUmtV/nJvZlK9/yDtZhYAw5tWmL8ToIn+9ljXTyujPU3l9MtYH
 mqPrgNgX7Ob6m6zu4uMgPRclQ281W/dYd5+x0Mgr94lcG43X9sgokow2ojP0b1v6WrfR
 kO8Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:references:mail-copies-to
 :gmane-reply-to-list:date:message-id:mime-version
 :content-transfer-encoding;
 bh=rUfaZXjVcobo9lScNESuGkfZTvNpuqTtGvrdZSFo5kE=;
 b=FWUqYR0lty7+qVDZxJEhNVjSouL20yiVkhR67xzbRwV/iCRP/ve+VVuneK0iqtFpxq
 i5L+nDbxkyfeqmzzqhmfDlDd+RXHMWTAL3KcxtzyvxnYooJqY6jWPYfnlCpljbwcsYxB
 JYrTMTdr/oaxW2307pHljLPA5hslVlS/LnYXm8vWw4wLG4PjcFLttkJg6Egoi+0Ru6NX
 wScWirfMpeAY8G1qKd4c09c8ixJFOvIL+sT6mo1QyjTI5zagpP0kO9TtgEs2JSgHM9H8
 fECt7Dp65CgGnH0TTGBTX5iTjRlS1+4nUu3j34F9Pf6OEEmT0/nnRDcYDMrJHUBW9gq7
 wGHA==
X-Gm-Message-State: ALQs6tA3f5dLMQQumLu2sOVSKZ9YoORSrEm7ic/4kiKGYRJkEuwZWXow
 jOK4SNF8fjweCQXFx4hRl3vIUyC2UWA=
X-Google-Smtp-Source: AIpwx4/b7g/wqJZBu2ptTUexqLVzyEgiC7MM+jNLnRFiviRYikH+EBsYGB7CFLWVzUD7Ucf116rJkw==
X-Received: by 10.28.190.3 with SMTP id o3mr167715wmf.57.1522843667661;
 Wed, 04 Apr 2018 05:07:47 -0700 (PDT)
Received: from rpluim (vav06-1-78-207-202-134.fbx.proxad.net. [78.207.202.134])
 by smtp.gmail.com with ESMTPSA id t8sm3971802wmc.20.2018.04.04.05.07.46
 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);
 Wed, 04 Apr 2018 05:07:46 -0700 (PDT)
From: Robert Pluim <rpluim@HIDDEN>
References: <ea1a2a97-0ec3-47fb-8e74-2590e3a7fc89@default>
 <5AC3232D.1020107@HIDDEN> <874lksy9vy.fsf@HIDDEN>
 <5AC35626.2070700@HIDDEN> <877epowjq9.fsf@HIDDEN>
 <5AC48386.8040901@HIDDEN>
Mail-Copies-To: never
Gmane-Reply-To-List: yes
Date: Wed, 04 Apr 2018 14:07:45 +0200
Message-ID: <87sh8bw4xa.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)

martin rudalics <rudalics@HIDDEN> writes:

>>> 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.

As noted elsewhere, I think this is a window manager issue. I=CA=BCd expect=
 those
two calls to give the same effect, which is what I see.

>> 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 so =
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.

I=CA=BCll have to retest this one, I may have missed a case.

>>>> [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 3840
>>    2094) (mm-size 350 190) (frames #<frame *unsent wide reply to martin
>>    rudalics* 0x3d5ce80> #<frame *info* 0x89f6ff0> #<frame *scratch* 0x87=
f1a00>)
>>    (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?

That I don=CA=BCt know, I=CA=BCll find out...

>>    (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.

I asked for 2400 because if I ask for 2360 the frame is not flush
right.

> BTW is this on a high resolution display?  Would/should we scale
> external borders on such a display too?

Yes, it=CA=BCs high resolution, but 20 pixels seems like more than can be
accounted for by scaling.

> martin
>
>> I=CA=BCll take a look at x_calc_absolute_position.

I think we=CA=BCre getting a -20 offset back from X somewhere when querying
the frame size/position. If I look at this hunk in
x_real_pos_and_offsets:

#ifdef USE_XCB
      geom =3D xcb_get_geometry_reply (xcb_conn, geom_cookie, NULL);
      if (geom)
	{
	  real_x =3D geom->x;

then real_x there is -20 when the frame is flush left. Should we be
using gdk/gtk calls to get the window geometry?

Robert

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#31031: 27.0; (elisp) `Position Parameters', floating-point values
Resent-From: martin rudalics <rudalics@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 05 Apr 2018 07:01:01 +0000
Resent-Message-ID: <handler.31031.B31031.152291163632214 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 31031
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Robert Pluim <rpluim@HIDDEN>
Cc: 31031 <at> debbugs.gnu.org
Received: via spool by 31031-submit <at> debbugs.gnu.org id=B31031.152291163632214
          (code B ref 31031); Thu, 05 Apr 2018 07:01:01 +0000
Received: (at 31031) by debbugs.gnu.org; 5 Apr 2018 07:00:36 +0000
Received: from localhost ([127.0.0.1]:38871 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1f3ysu-0008NW-5g
	for submit <at> debbugs.gnu.org; Thu, 05 Apr 2018 03:00:36 -0400
Received: from mout.gmx.net ([212.227.15.18]:37281)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rudalics@HIDDEN>) id 1f3ysr-0008NG-Lw
 for 31031 <at> debbugs.gnu.org; Thu, 05 Apr 2018 03:00:34 -0400
Received: from [192.168.1.100] ([212.95.5.100]) by mail.gmx.com (mrgmx003
 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MVMgI-1f1DDo3zVW-00YjTZ; Thu, 05
 Apr 2018 09:00:27 +0200
Message-ID: <5AC5C981.30700@HIDDEN>
Date: Thu, 05 Apr 2018 09:00:17 +0200
From: martin rudalics <rudalics@HIDDEN>
MIME-Version: 1.0
References: <ea1a2a97-0ec3-47fb-8e74-2590e3a7fc89@default>	<5AC3232D.1020107@HIDDEN>
 <874lksy9vy.fsf@HIDDEN>	<5AC35626.2070700@HIDDEN>
 <877epowjq9.fsf@HIDDEN>	<5AC48386.8040901@HIDDEN>
 <87sh8bw4xa.fsf@HIDDEN>
In-Reply-To: <87sh8bw4xa.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:3c31+nHkWIgEVBu3DZZBQP1dpCJN985n6NVNlLozMsjIdWP+B/N
 JRo9GmxS1SXRiSfbLKny12IAtSujYp78gLX7zk9XGnsJohp3McY2NWxpQ7WIrWVzQp/8+0s
 KNydzJy3by3f8NiHad9mRBA9htQVBQhHc5bewuw8GlqqBJrTESCKCV4yCIMCOPfAidRkJOb
 AXiTaskQewRRK0Zn9lmLA==
X-UI-Out-Filterresults: notjunk:1;V01:K0:2ePNC0bDPXo=:ufwVDDMDBgb2vgBF1ruG9C
 hUCspU1G6MpdeqX3T84xqLHIcuBlRE60kMJO+G4/vbWgKSU+/ZQDXFtL0Z0chc5ru5iLR0Kfc
 ptlz/6OCHvkPXLuK8aWFUIbzV1QLNUTIxCJ3/fwjkNNBh6lCihoYDfi2IW5VBLUYpxq9u+hS6
 arbmT3qKsio9cKE26qDbFd05Qn6JnbAloX8hY/fGurchWszK6Y+rFhcLhpcnoy3Z5ZC7nV0lF
 0GNvO+b0YTMaxQrSLBLn2+tSHTeH8iTWwz9rwD9Uv7rEDFJ9ZZVoa6xHHKcjAykIL6eVxjSW/
 uLaIALkM05C5lnE0EoyrTQmweHRgN9DB5yA+YjXSZQCewjCuTAmX57T63HNxbv7b94og4KTNY
 pxgeBYFVw9IDF6ZH81SpNyChv/LBnl9h6KUOjvjAsP7hL3/0dWU9QjvmKTpHxg3xAK8LfAOhu
 AHgrWSN55CwWpi8HKhQOg7rspyHQJAy/2O1ASv6uUVQdmbKL0CIn/RepA6pS3cck5L4ZDpJvg
 eCHi8TgZ4awbVcAmiuW5MjB0QdcY68Hmto6SmqIWHX9U2FILMlvAkQcstYfIiS2kFskUNmAhU
 wbXYLKSmfwdsA1Q0s2Fh2Nb4cDrg8i7krOsewTx8jyMjf+8QfhrIcQQNSGh3uTp8KtlgMFApr
 /i4Yfys3GyvLkAKpBEgqaT7mFDbi/QKUtgWooW/1QB0V8EM27uE57pRgvxVfIfUFw19sllzbX
 nkagkhxol55LSWU20T0uMp1DilLxLXNxWRyljoTfGw8XlAwL0LKQh5ZbFgHZhn3TF+gU0tTW6
 08ldVrls46uW/39lmGx12AZncSM1yNJk+VZW8jfy+PFQlHuHWg=
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

 >> 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 (th=
e
 >> full right external border) missing on the right if not I am missing
 >> something.
 >
 > I asked for 2400 because if I ask for 2360 the frame is not flush
 > right.

Funny.  There must be some strange calculations going on behind the
scenes.  Is there some consistency in the sense that your window
manager never shows the full external border when you want to place it
at some position on the left or top of the screen?

 > I think we=CA=BCre getting a -20 offset back from X somewhere when que=
rying
 > the frame size/position.

And the -20 doesn't correspond to what you see on screen because the
external border is not fully visible.  Right?

 > If I look at this hunk in
 > x_real_pos_and_offsets:
 >
 > #ifdef USE_XCB
 >        geom =3D xcb_get_geometry_reply (xcb_conn, geom_cookie, NULL);
 >        if (geom)
 > 	{
 > 	  real_x =3D geom->x;
 >
 > then real_x there is -20 when the frame is flush left. Should we be
 > using gdk/gtk calls to get the window geometry?

By all means try to check whether these get you better results.  But
before that you might want to try disabling USE_XCB.  I recall an
earlier discussion where I strongly doubted the correctness of values
returned by x_real_pos_and_offsets.

martin

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#31031: 27.0; (elisp) `Position Parameters', floating-point values
Resent-From: Robert Pluim <rpluim@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 05 Apr 2018 14:22:02 +0000
Resent-Message-ID: <handler.31031.B31031.152293807515293 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 31031
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: martin rudalics <rudalics@HIDDEN>
Cc: 31031 <at> debbugs.gnu.org
Received: via spool by 31031-submit <at> debbugs.gnu.org id=B31031.152293807515293
          (code B ref 31031); Thu, 05 Apr 2018 14:22:02 +0000
Received: (at 31031) by debbugs.gnu.org; 5 Apr 2018 14:21:15 +0000
Received: from localhost ([127.0.0.1]:39545 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1f45lL-0003yb-9d
	for submit <at> debbugs.gnu.org; Thu, 05 Apr 2018 10:21:15 -0400
Received: from mail-wm0-f44.google.com ([74.125.82.44]:39041)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rpluim@HIDDEN>) id 1f45lK-0003yO-3j
 for 31031 <at> debbugs.gnu.org; Thu, 05 Apr 2018 10:21:14 -0400
Received: by mail-wm0-f44.google.com with SMTP id f125so7600665wme.4
 for <31031 <at> debbugs.gnu.org>; Thu, 05 Apr 2018 07:21:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:references:mail-copies-to:gmane-reply-to-list
 :date:in-reply-to:message-id:mime-version:content-transfer-encoding;
 bh=2f19jsbr3lhfxnm+ZPFfdI+2hrQDWlf8tZut+bAKXFw=;
 b=iBUMF1rHRyJz12rn40gdu6xZOfn7BTS77cca/8pOMyZXf4tmd9TcuwwV5AySli3rew
 2ZL8aGeo2BYmZmNo2gRlgWVBjhYq0MpjixcZ3l+zZdCINAGoCf5XKWFCekXyADx8ndwV
 z5gEW90m64o0PPcX1UC0/CsAUDcCZJW5kCxnFbG/eg/kqowPbQfQ8oz4NETawZgmWuOH
 5BICOUfxMa/i08FX0i7/icdBcduqZQkV7ROu1EVhJHw0q2BYkGzO3XUQFKYdJUeulsfX
 bPHIrLQMzybGkQOPQ8dW5pFIVdH/OfcZer9RVoDPGUERxPTBLA26DywNrKjZ7srrAOaR
 iZfA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:references:mail-copies-to
 :gmane-reply-to-list:date:in-reply-to:message-id:mime-version
 :content-transfer-encoding;
 bh=2f19jsbr3lhfxnm+ZPFfdI+2hrQDWlf8tZut+bAKXFw=;
 b=pCzvQo+7sySONuLNwP6HCCgOebon/r6waQ9+YWtq0TdLIJc3YlXnp1YJIEAsjwOrJx
 5vXgD94U9iKqq3XCNbxEkXbjWJyapYdEVGf06r7pRM+quVZ/rs7RHd/XM4/Hyj7cKXMY
 pxaK8TvoeGQgtTt9ts3+JB29wmCgEV0B905Y6VEi904ffC0hNraf2033vMFbFcAA7M09
 1naydvOdkiqo4BeCkU3Rk5FUZo/gpbT4g9YVqKEj9wsxsqCLf2TV8AFCZIU8AhSrj4wX
 Qi9oeAPkBox80m0mv06+nsCgGY4tK8qrxdJ9Vyj8IM2qj17ULgBagtHToVsqW3RLoacR
 BPiw==
X-Gm-Message-State: AElRT7GFuPlJh+jptXXiOi+IfHZVynq47D6nLvCpyPrtOatwTLzQg2aw
 yukLEK4KW9c2eumcrMRlrDoK9VrQ
X-Google-Smtp-Source: AIpwx4+3akU9B+eaL446buUZXRQHIfMoA42B+xW/JMtMQvqLLA5Va+iJXE4GmoGBr5refmN4eqCPww==
X-Received: by 10.28.226.138 with SMTP id z132mr10010288wmg.101.1522938063194; 
 Thu, 05 Apr 2018 07:21:03 -0700 (PDT)
Received: from rpluim ([149.5.228.1])
 by smtp.gmail.com with ESMTPSA id m83sm3579008wma.17.2018.04.05.07.21.01
 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);
 Thu, 05 Apr 2018 07:21:02 -0700 (PDT)
From: Robert Pluim <rpluim@HIDDEN>
References: <ea1a2a97-0ec3-47fb-8e74-2590e3a7fc89@default>
 <5AC3232D.1020107@HIDDEN> <874lksy9vy.fsf@HIDDEN>
 <5AC35626.2070700@HIDDEN> <877epowjq9.fsf@HIDDEN>
 <5AC48386.8040901@HIDDEN> <87sh8bw4xa.fsf@HIDDEN>
 <5AC5C981.30700@HIDDEN>
Mail-Copies-To: never
Gmane-Reply-To-List: yes
Date: Thu, 05 Apr 2018 16:21:01 +0200
In-Reply-To: <5AC5C981.30700@HIDDEN> (martin rudalics's message of "Thu, 05
 Apr 2018 09:00:17 +0200")
Message-ID: <87k1tl68fm.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)

martin rudalics <rudalics@HIDDEN> writes:

>>> 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.
>>
>> I asked for 2400 because if I ask for 2360 the frame is not flush
>> right.
>
> Funny.  There must be some strange calculations going on behind the
> scenes.  Is there some consistency in the sense that your window
> manager never shows the full external border when you want to place it
> at some position on the left or top of the screen?
>

No, I haven't noticed any artifacts like that.

>> I think we=CA=BCre getting a -20 offset back from X somewhere when query=
ing
>> the frame size/position.
>
> And the -20 doesn't correspond to what you see on screen because the
> external border is not fully visible.  Right?
>

What there is of the external border is fully visible, since the frame
is not flush right (except when I ask for 2400, that is).

>> If I look at this hunk in
>> x_real_pos_and_offsets:
>>
>> #ifdef USE_XCB
>>        geom =3D xcb_get_geometry_reply (xcb_conn, geom_cookie, NULL);
>>        if (geom)
>> 	{
>> 	  real_x =3D geom->x;
>>
>> then real_x there is -20 when the frame is flush left. Should we be
>> using gdk/gtk calls to get the window geometry?
>
> By all means try to check whether these get you better results.  But
> before that you might want to try disabling USE_XCB.  I recall an
> earlier discussion where I strongly doubted the correctness of values
> returned by x_real_pos_and_offsets.

Some of them do seem bogus. disabling USE_XCB has no effect on the
values (I have a vague memory of Xlib using XCB behind the scenes now,
so that=CA=BCs not too surprising)

I=CA=BCll see if I can change the guts of x_real_pos_and_offsets to use
GDK directly, that might fix things.

Robert

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#31031: 27.0; (elisp) `Position Parameters', floating-point values
Resent-From: Robert Pluim <rpluim@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 06 Apr 2018 10:29:02 +0000
Resent-Message-ID: <handler.31031.B31031.15230105307188 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 31031
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: martin rudalics <rudalics@HIDDEN>
Cc: 31031 <at> debbugs.gnu.org
Received: via spool by 31031-submit <at> debbugs.gnu.org id=B31031.15230105307188
          (code B ref 31031); Fri, 06 Apr 2018 10:29:02 +0000
Received: (at 31031) by debbugs.gnu.org; 6 Apr 2018 10:28:50 +0000
Received: from localhost ([127.0.0.1]:39884 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1f4Oby-0001rs-7J
	for submit <at> debbugs.gnu.org; Fri, 06 Apr 2018 06:28:50 -0400
Received: from mail-wr0-f180.google.com ([209.85.128.180]:42933)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rpluim@HIDDEN>) id 1f4Obw-0001rf-6S
 for 31031 <at> debbugs.gnu.org; Fri, 06 Apr 2018 06:28:48 -0400
Received: by mail-wr0-f180.google.com with SMTP id s18so1203098wrg.9
 for <31031 <at> debbugs.gnu.org>; Fri, 06 Apr 2018 03:28:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:references:mail-copies-to:gmane-reply-to-list
 :date:in-reply-to:message-id:mime-version:content-transfer-encoding;
 bh=4zzIj/5rts1nYLkwYTFQPMM7XOWpYaFMJiPb5qalKiM=;
 b=M+CFKPtNBvAIR0aQiOQVentr1CjCB05VkNjjSgB++TSydyE7BB2eXhtHDv9EJ3fV61
 t5QAyD5/myLBR3cFNphinkFb0R2Zg3/uC0FmO1R7m2xTXIKEwaATTBgtOS4cs84VuAWl
 Q1KV9qyYNc1D7WstGpsjkPsobWx1RZnpDvO0MV6goAxD90giSU2t/Pl8Dg4UcCNpAUPu
 CaWM3YS0WmjClIqL+iuU5SwVCyXoahukPuo8JXoZ7HLXNkAhs1XGzcP+n5yHKrCQP3gq
 59nkvYeZvwPFr3lHNtS0U4Jhj7NidBLohSTRT5aYkeiYK5GX7kZn0ZRKFVKQyu4wIR2C
 AvkQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:references:mail-copies-to
 :gmane-reply-to-list:date:in-reply-to:message-id:mime-version
 :content-transfer-encoding;
 bh=4zzIj/5rts1nYLkwYTFQPMM7XOWpYaFMJiPb5qalKiM=;
 b=GhcCh2M6CMGWVvQwW1MeqjFi6flj5uPBt+Zd/Z0bx6KIoRSTe85o6/MxfzL5Yr5d19
 3DvbvhxXBZNFfWMTb/DrQwvlLVLbxjUq0SVc0HDUyrznmhBdd3hpkA/3LxPl68nvMnEN
 yC0RPaZ7TLT6IujIHT9ev9pAPcaXjbhm0aEJZjv2/W83g6/Hk6pg/PtEEtMVHUb/EkdI
 Gk1b8LBc6YBM4lodle6P9DYyw38jljT4iZOdUM4cZjNNIohaBkt+8FtbmUFD/wu/hkgk
 sBYV+djDCwq365zU7q2QHM/Y1gbXMnzLgXaHpIyA02PKA62mFukv5eDi70yn9//9WjB5
 mn0g==
X-Gm-Message-State: AElRT7GDBJ3eumkoGdyZ48BjTRINxQdwcYM6gZYS8rnANDnTCXyMEqgb
 G8KX0tsq3zLZfXFQRpGx4HrnUeKV
X-Google-Smtp-Source: AIpwx49rJcD29SGaescmmHxOh7oFeBOesBWpZhN6Hjcgq9uAC3oDIrAJETLkBFd+FFZ2Jx5i2Hs67w==
X-Received: by 10.223.219.16 with SMTP id s16mr20796364wri.123.1523010521981; 
 Fri, 06 Apr 2018 03:28:41 -0700 (PDT)
Received: from rpluim ([149.5.228.1])
 by smtp.gmail.com with ESMTPSA id r75sm5919641wmf.34.2018.04.06.03.28.40
 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);
 Fri, 06 Apr 2018 03:28:41 -0700 (PDT)
From: Robert Pluim <rpluim@HIDDEN>
References: <ea1a2a97-0ec3-47fb-8e74-2590e3a7fc89@default>
 <5AC3232D.1020107@HIDDEN> <874lksy9vy.fsf@HIDDEN>
 <5AC35626.2070700@HIDDEN> <877epowjq9.fsf@HIDDEN>
 <5AC48386.8040901@HIDDEN> <87sh8bw4xa.fsf@HIDDEN>
Mail-Copies-To: never
Gmane-Reply-To-List: yes
Date: Fri, 06 Apr 2018 12:28:38 +0200
In-Reply-To: <87sh8bw4xa.fsf@HIDDEN> (Robert Pluim's message of "Wed, 04
 Apr 2018 14:07:45 +0200")
Message-ID: <87fu48pr1l.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.0 (/)

Robert Pluim <rpluim@HIDDEN> writes:

>>> 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 so=
 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.
>
> I=CA=BCll have to retest this one, I may have missed a case.

Two monitors, one above the other, frame on bottom one.

(modify-frame-parameters nil '((top .   0.0)))
  =3D> frame moves to top monitor
(modify-frame-parameters nil '((top .   1.0)))
  =3D> frame moves tobottom monitor

Repeating those commands cycles between top and bottom monitor.

(and they're not flush to the edges, but this is with GDK scaling
going on, so I=CA=BCm not too surprised by that).

Two monitors, one next to the other, frame on right one.

(modify-frame-parameters nil '((left .   0.0)))
  =3D> frame moves to left monitor
(modify-frame-parameters nil '((left .   1.0)))
  =3D> frame moves to right monitor

and again this cycles between the monitors. So whatever I tested
before, it wasn't this, and the behaviour is consistent between "left"
and "top".

I can't find anything in the elisp manual describing that the
workareas of the two monitors are combined like this.  Should such
information go in (elisp)Multiple Terminals, or (emacs)Multiple
Displays? Or both?

Robert

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#31031: 27.0; (elisp) `Position Parameters', floating-point values
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 06 Apr 2018 12:57:02 +0000
Resent-Message-ID: <handler.31031.B31031.152301941627538 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 31031
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Robert Pluim <rpluim@HIDDEN>
Cc: rudalics@HIDDEN, 31031 <at> debbugs.gnu.org
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 31031-submit <at> debbugs.gnu.org id=B31031.152301941627538
          (code B ref 31031); Fri, 06 Apr 2018 12:57:02 +0000
Received: (at 31031) by debbugs.gnu.org; 6 Apr 2018 12:56:56 +0000
Received: from localhost ([127.0.0.1]:39931 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1f4QvI-0007A6-7n
	for submit <at> debbugs.gnu.org; Fri, 06 Apr 2018 08:56:56 -0400
Received: from eggs.gnu.org ([208.118.235.92]:49900)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1f4QvG-00079t-FK
 for 31031 <at> debbugs.gnu.org; Fri, 06 Apr 2018 08:56:54 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1f4Qv8-0000bV-BM
 for 31031 <at> debbugs.gnu.org; Fri, 06 Apr 2018 08:56:49 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_05,T_RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:48150)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1f4Qv8-0000bH-6h; Fri, 06 Apr 2018 08:56:46 -0400
Received: from [176.228.60.248] (port=4902 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1f4Qv7-0005vz-IA; Fri, 06 Apr 2018 08:56:45 -0400
Date: Fri, 06 Apr 2018 15:56:42 +0300
Message-Id: <83in941oj9.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <87fu48pr1l.fsf@HIDDEN> (message from Robert Pluim on Fri, 06
 Apr 2018 12:28:38 +0200)
References: <ea1a2a97-0ec3-47fb-8e74-2590e3a7fc89@default>
 <5AC3232D.1020107@HIDDEN> <874lksy9vy.fsf@HIDDEN>
 <5AC35626.2070700@HIDDEN> <877epowjq9.fsf@HIDDEN>
 <5AC48386.8040901@HIDDEN> <87sh8bw4xa.fsf@HIDDEN>
 <87fu48pr1l.fsf@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -5.0 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -6.0 (------)

> From: Robert Pluim <rpluim@HIDDEN>
> Date: Fri, 06 Apr 2018 12:28:38 +0200
> Cc: 31031 <at> debbugs.gnu.org
> 
> I can't find anything in the elisp manual describing that the
> workareas of the two monitors are combined like this.

AFAIK, this depends on how the monitors are configured, and perhaps
also on the window manager.  The "Multiple Terminals" node in ELisp
manual is what we felt we could document, and it does hint at what you
see, if you read the text carefully.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#31031: 27.0; (elisp) `Position Parameters', floating-point values
Resent-From: Robert Pluim <rpluim@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 06 Apr 2018 13:10:01 +0000
Resent-Message-ID: <handler.31031.B31031.152302019528714 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 31031
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 31031 <at> debbugs.gnu.org
Received: via spool by 31031-submit <at> debbugs.gnu.org id=B31031.152302019528714
          (code B ref 31031); Fri, 06 Apr 2018 13:10:01 +0000
Received: (at 31031) by debbugs.gnu.org; 6 Apr 2018 13:09:55 +0000
Received: from localhost ([127.0.0.1]:39935 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1f4R7r-0007T4-DS
	for submit <at> debbugs.gnu.org; Fri, 06 Apr 2018 09:09:55 -0400
Received: from mail-wr0-f172.google.com ([209.85.128.172]:37450)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rpluim@HIDDEN>) id 1f4R7p-0007Sr-ML
 for 31031 <at> debbugs.gnu.org; Fri, 06 Apr 2018 09:09:54 -0400
Received: by mail-wr0-f172.google.com with SMTP id l49so1730458wrl.4
 for <31031 <at> debbugs.gnu.org>; Fri, 06 Apr 2018 06:09:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:references:mail-copies-to:gmane-reply-to-list
 :date:in-reply-to:message-id:mime-version;
 bh=9p5t6DEU6Z/yUDqm99Zbf98RHaYcD2lYJIKOB9Gi2hU=;
 b=NZAwwJqwhJhfJwGdVqjcJ1lbIY0G9iVkLmPXR6OOL1j0toumI1Vx9x/aKGx1Aq1ivJ
 5M/QPs1+3RfT9uWoDJbaOnTtD4WUzRNGLEAhTipOnz84/dILqmwlnO3g1ppO0VgW4OdG
 lwuR2LedvQFXkqPdaem/8EzFXERaW5CVl0BchzchKaE7kfFA+1/qHv3R7howr1vw9bwF
 3J1s5mpQiDRfUmzBpiGmXSh2xMymo60ruLl0rCjojX7C61Lw+F8doY7BlFUHfbghEz5G
 XMcYSOjF9x663J6eWl8L6w/60B8By6FK4YqClBFa9Qwphqd2rUPLgFiehxFGjQAxBI6p
 fKcw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:references:mail-copies-to
 :gmane-reply-to-list:date:in-reply-to:message-id:mime-version;
 bh=9p5t6DEU6Z/yUDqm99Zbf98RHaYcD2lYJIKOB9Gi2hU=;
 b=avo0jfPVQmFBzlwhQfPOIWQxpzLfawLDNR45Lm3t5hfTKL6kXZoY+hzyrqPX2SRWFB
 blPYxXsXm+f4rOARIMxI3CGW8htEKlIulVvAc+7K/VluhrVfFPK4rIz/tg3KRqgCnwwT
 EqMFc5pYxKva75GiXeBmmeRXx8X6xVn2yxvt8HVZ1S++1NARQxFlkSoliZ/6d6A3LuUu
 QKY24nuJGSyzT2E5XKP8ge4P8ywYMeyDy+Kjv8ED2C5wUUxLQwjlVjJ7Bnd61h1mzl9d
 YAJ7u7z3rrwXd7gFf+GL+mPXMZyVT+QlUVlg8Bguxxuep13xpSc7IvDEgVSRAQEpZJyp
 yZUA==
X-Gm-Message-State: AElRT7E2SeF2rLVVkZyTv/PKHJcCDnLZK/QUWS25vav1VoS+al8cfzeO
 97MMkq/L63woiFwbnefnf6SWYvtv
X-Google-Smtp-Source: AIpwx4+RfBH6pj+J+Sx/i2BGtPIcU6rZby0LilDAhH+G5Pa1CXro4RrpfHXunWdmiaC75p2vLBsFPQ==
X-Received: by 10.223.181.149 with SMTP id c21mr20522392wre.233.1523020187385; 
 Fri, 06 Apr 2018 06:09:47 -0700 (PDT)
Received: from rpluim ([149.5.228.1])
 by smtp.gmail.com with ESMTPSA id 14sm9660591wml.41.2018.04.06.06.09.46
 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);
 Fri, 06 Apr 2018 06:09:46 -0700 (PDT)
From: Robert Pluim <rpluim@HIDDEN>
References: <ea1a2a97-0ec3-47fb-8e74-2590e3a7fc89@default>
 <5AC3232D.1020107@HIDDEN> <874lksy9vy.fsf@HIDDEN>
 <5AC35626.2070700@HIDDEN> <877epowjq9.fsf@HIDDEN>
 <5AC48386.8040901@HIDDEN> <87sh8bw4xa.fsf@HIDDEN>
 <87fu48pr1l.fsf@HIDDEN> <83in941oj9.fsf@HIDDEN>
Mail-Copies-To: never
Gmane-Reply-To-List: yes
Date: Fri, 06 Apr 2018 15:09:46 +0200
In-Reply-To: <83in941oj9.fsf@HIDDEN> (Eli Zaretskii's message of "Fri, 06 Apr
 2018 15:56:42 +0300")
Message-ID: <873708pjl1.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Eli Zaretskii <eliz@HIDDEN> writes:

>> From: Robert Pluim <rpluim@HIDDEN>
>> Date: Fri, 06 Apr 2018 12:28:38 +0200
>> Cc: 31031 <at> debbugs.gnu.org
>> 
>> I can't find anything in the elisp manual describing that the
>> workareas of the two monitors are combined like this.
>
> AFAIK, this depends on how the monitors are configured, and perhaps
> also on the window manager.  The "Multiple Terminals" node in ELisp
> manual is what we felt we could document, and it does hint at what you
> see, if you read the text carefully.

I guess you mean this bit: "The third part, SCREENNUMBER, identifies a
zero-based screen number (a separate monitor) that is part of a single
monitor collection on that X server."

How about adding something like "Such a collection is often treated as
one bigger virtual screen." ?

Robert

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#31031: 27.0; (elisp) `Position Parameters', floating-point values
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 06 Apr 2018 13:20:02 +0000
Resent-Message-ID: <handler.31031.B31031.152302076529588 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 31031
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Robert Pluim <rpluim@HIDDEN>
Cc: 31031 <at> debbugs.gnu.org
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 31031-submit <at> debbugs.gnu.org id=B31031.152302076529588
          (code B ref 31031); Fri, 06 Apr 2018 13:20:02 +0000
Received: (at 31031) by debbugs.gnu.org; 6 Apr 2018 13:19:25 +0000
Received: from localhost ([127.0.0.1]:39951 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1f4RH3-0007hA-0r
	for submit <at> debbugs.gnu.org; Fri, 06 Apr 2018 09:19:25 -0400
Received: from eggs.gnu.org ([208.118.235.92]:36451)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1f4RH1-0007gv-Hg
 for 31031 <at> debbugs.gnu.org; Fri, 06 Apr 2018 09:19:23 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1f4RGs-0005Ys-7e
 for 31031 <at> debbugs.gnu.org; Fri, 06 Apr 2018 09:19:18 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,T_RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:48526)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1f4RGs-0005Yo-3b; Fri, 06 Apr 2018 09:19:14 -0400
Received: from [176.228.60.248] (port=4933 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1f4RGq-0004Yn-SU; Fri, 06 Apr 2018 09:19:13 -0400
Date: Fri, 06 Apr 2018 16:19:10 +0300
Message-Id: <83d0zc1nht.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <873708pjl1.fsf@HIDDEN> (message from Robert Pluim on Fri, 06
 Apr 2018 15:09:46 +0200)
References: <ea1a2a97-0ec3-47fb-8e74-2590e3a7fc89@default>
 <5AC3232D.1020107@HIDDEN> <874lksy9vy.fsf@HIDDEN>
 <5AC35626.2070700@HIDDEN> <877epowjq9.fsf@HIDDEN>
 <5AC48386.8040901@HIDDEN> <87sh8bw4xa.fsf@HIDDEN>
 <87fu48pr1l.fsf@HIDDEN> <83in941oj9.fsf@HIDDEN>
 <873708pjl1.fsf@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -5.0 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -6.0 (------)

> From: Robert Pluim <rpluim@HIDDEN>
> Cc: 31031 <at> debbugs.gnu.org
> Date: Fri, 06 Apr 2018 15:09:46 +0200
> 
> > AFAIK, this depends on how the monitors are configured, and perhaps
> > also on the window manager.  The "Multiple Terminals" node in ELisp
> > manual is what we felt we could document, and it does hint at what you
> > see, if you read the text carefully.
> 
> I guess you mean this bit: "The third part, SCREENNUMBER, identifies a
> zero-based screen number (a separate monitor) that is part of a single
> monitor collection on that X server."

Also, this:

     On some multi-monitor setups, a single X display outputs to more than
  one physical monitor.  You can use the functions
  ‘display-monitor-attributes-list’ and ‘frame-monitor-attributes’ to
  obtain information about such setups.

And this:

       ‘geometry’
	    Position of the top-left corner of the monitor’s screen and
	    its size, in pixels, as ‘(X Y WIDTH HEIGHT)’.  Note that, if
	    the monitor is not the primary monitor, some of the
	    coordinates might be negative.

> How about adding something like "Such a collection is often treated as
> one bigger virtual screen." ?

Sure, anything that might help understanding the issue without being
too definitive, provided that Martin is happy with the text.

Thanks.

Last modified: Mon, 25 Nov 2019 12:00:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.