bug#31031: 27.0; (elisp) `Position Parameters', floating-point values

[Robert Pluim]

martin rudalics <rudalics@gmx.at> 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ʼs 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ʼt 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ʼs a different issue