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

[martin rudalics]

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

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ʼt matter, only the relative
> 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ʼs a different issue

Probably a problem with calculating the decorations.  Does
(frame-geometry) return "reasonable" values for your frame?

martin