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

Previous Next

Full log

Message #14 received at 31031 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: Drew Adams <drew.adams <at> oracle.com>, 31031 <at> debbugs.gnu.org
Subject: Re: bug#31031: 27.0; (elisp) `Position Parameters', floating-point
 values
Date: Tue, 03 Apr 2018 12:23:34 +0200

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

Previous Next

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