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

From: Robert Pluim <[email-masked]>
Date: Tue, 03 Apr 2018 14:35:42 +0200

martin rudalics <[email-masked]> 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ʼ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ʼm 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ʼm undecided so far
as to which I think is the "correct" behaviour.

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

(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* 0x87f1a00>)
  (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) => 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ʼs a (-20) error for the outer-position at
least.

Iʼll take a look at x_calc_absolute_position.

Robert