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

[martin rudalics <rudalics@gmx.at>]

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