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

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

[Drew Adams]

I'm afraid this reads a bit like gobbledygook, to me.

And if I think I understand it, it doesn't seem to correspond to the
behavior I see.

Of course, the "out" is that it says, "In general, it is not a good idea
to position a frame relative to the right or bottom edge of its
display."  But the only case discussed in that context is an initial/new
frame.  And there is a similar caveat about using not using
floating-point with decorated frames.  But again, it speaks only about
"when CREATING decorated frames. 

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

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)))
(modify-frame-parameters nil '((left . - 0.0)))
(modify-frame-parameters nil '((left .   1.0)))
(modify-frame-parameters nil '((left . - 1.0)))

(And adding (user-position . t) changes nothing in this regard.)

What am I misunderstanding, here?  Can this text please be made more
clear?  It's not really clear how floating-point values are supposed to
be used or what they are supposed to do.  Dunno whether the behavior I'm
seeing is bugged or the doc is wrong or I'm misunderstanding it.


In GNU Emacs 27.0.50 (build 3, x86_64-w64-mingw32)
 of 2018-03-21
Repository revision: e70d0c9e66d7a8609450b2889869d16aeb0363b5
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --without-dbus --host=x86_64-w64-mingw32
 --without-compress-install -C 'CFLAGS=-O2 -static -g3''

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

[martin rudalics]

 > Of course, the "out" is that it says, "In general, it is not a good idea
 > to position a frame relative to the right or bottom edge of its
 > display."  But the only case discussed in that context is an initial/new
 > frame.

It also talks about how these positions are stored and restored, for
example, when saving the desktop.

 > And there is a similar caveat about using not using
 > floating-point with decorated frames.  But again, it speaks only about
 > "when CREATING decorated frames.

Because Emacs does not know the size of decorations _before_ a frame
has been created.

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

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

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.

 > (modify-frame-parameters nil '((left . - 1.0)))

See above.

 > (And adding (user-position . t) changes nothing in this regard.)

'user-position' has no effect on Windows and can be silently ignored
by window managers on GNU/Linux.  Don't rely on it.

 > What am I misunderstanding, here?  Can this text please be made more
 > clear?  It's not really clear how floating-point values are supposed to
 > be used or what they are supposed to do.  Dunno whether the behavior I'm
 > seeing is bugged or the doc is wrong or I'm misunderstanding it.

Please state what you do not understand or can be improved in this
text:

           A floating-point value in the range 0.0 to 1.0 specifies the
           left edge's offset via the "left position ratio" of the
           frame--the ratio of the left edge of its outer frame to the
           width of the frame's workarea (*note Multiple Terminals::) or
           its parent's native frame (*note Child Frames::) minus the
           width of the outer frame.  Thus, a left position ratio of 0.0
           flushes a frame to the left, a ratio of 0.5 centers it and a
           ratio of 1.0 flushes it to the right of its display or parent
           frame.  Similarly, the "top position ratio" of a frame is the
           ratio of the frame's top position to the height of its
           workarea or parent frame minus the height of the frame.

           Emacs will try to keep the position ratios of a child frame
           unaltered if that frame has a non-`nil' `keep-ratio' parameter
           (*note Frame Interaction Parameters::) and its parent frame
           is resized.

           Since the outer size of a frame (*note Frame Geometry::) is
           usually unavailable before a frame has been made visible, it
           is generally not advisable to use floating-point values when
           creating decorated frames.  Floating-point values are more
           suited for ensuring that an (undecorated) child frame is
           positioned nicely within the area of its parent frame.

In particular, it states that specifying floating point values is more
suited for child frames than for normal frames although by design they
should work for the latter too.

Thanks, martin

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

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

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

[Robert Pluim]

martin rudalics <rudalics@gmx.at> 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

modify-frame-parameters with floating point offsets

[Robert Pluim]

Robert Pluim <rpluim@gmail.com> writes:

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

OK, is this normal?

emacs -Q
(modify-frame-parameters nil '((left .   0.0)))
(frame-geometry)

=> ((outer-position -20 . 188) (outer-size 1208 . 1226)
   (external-border-size 20 . 20) (outer-border-width . 0)
   (title-bar-size 0 . 70) (menu-bar-external . t) (menu-bar-size 1168
   . 24) (tool-bar-external . t) (tool-bar-position . top) (tool-bar-size
   1168 . 42) (internal-border-width . 0))

The frame is visually flush with the left edge of the screen, but
frame-geometry claims itʼs at -20 ?

For comparison, after toggle-frame-fullscreen

((outer-position 0 . 0) (outer-size 3840 . 2160) (external-border-size
0 . 0) (outer-border-width . 0) (title-bar-size 0 . 0)
(menu-bar-external . t) (menu-bar-size 3840 . 24) (tool-bar-external
. t) (tool-bar-position . top) (tool-bar-size 3840 . 42)
(internal-border-width . 0))

So is this the window manager lying to us? This is with XWayland, Iʼll
see if I can test under vanilla X.

Robert

Re: modify-frame-parameters with floating point offsets

[Robert Pluim]

Robert Pluim <rpluim@gmail.com> writes:

> Robert Pluim <rpluim@gmail.com> writes:
>
>>> Probably a problem with calculating the decorations.  Does
>>> (frame-geometry) return "reasonable" values for your frame?
>
> OK, is this normal?
>
> emacs -Q
> (modify-frame-parameters nil '((left .   0.0)))
> (frame-geometry)
>
> => ((outer-position -20 . 188) (outer-size 1208 . 1226)
>    (external-border-size 20 . 20) (outer-border-width . 0)
>    (title-bar-size 0 . 70) (menu-bar-external . t) (menu-bar-size 1168
>    . 24) (tool-bar-external . t) (tool-bar-position . top) (tool-bar-size
>    1168 . 42) (internal-border-width . 0))
>
> The frame is visually flush with the left edge of the screen, but
> frame-geometry claims itʼs at -20 ?
>
> For comparison, after toggle-frame-fullscreen
>
> ((outer-position 0 . 0) (outer-size 3840 . 2160) (external-border-size
> 0 . 0) (outer-border-width . 0) (title-bar-size 0 . 0)
> (menu-bar-external . t) (menu-bar-size 3840 . 24) (tool-bar-external
> . t) (tool-bar-position . top) (tool-bar-size 3840 . 42)
> (internal-border-width . 0))
>
> So is this the window manager lying to us? This is with XWayland, Iʼll
> see if I can test under vanilla X.

So this seems to be very window-manager specific. With two different
implementations of Gnome-on-X-on-Wayland, I get the -20 offset, also
with one implementation of Gnome-on-X. However GTK running under KDE
does not have the issue. Also running Compiz-on-Gnome gets me the
correct answer, but Metacity gets it wrong.

That suggests to me itʼs a window manager issue, but Iʼm not sure how
we could work around the differences.

Robert

Re: modify-frame-parameters with floating point offsets

[martin rudalics]

 > So this seems to be very window-manager specific. With two different
 > implementations of Gnome-on-X-on-Wayland, I get the -20 offset, also
 > with one implementation of Gnome-on-X. However GTK running under KDE
 > does not have the issue. Also running Compiz-on-Gnome gets me the
 > correct answer, but Metacity gets it wrong.
 >
 > That suggests to me itʼs a window manager issue, but Iʼm not sure how
 > we could work around the differences.

The first question we have to resolve is whether the -20 offset
corresponds to what you see on screen - that is whether the left
external border is visible.  Maybe some windowing managers now break
with the tradition to expect the position of the "outer frame" and the
size of the "native frame".

martin

Re: modify-frame-parameters with floating point offsets

[martin rudalics]

 > OK, is this normal?
 >
 > emacs -Q
 > (modify-frame-parameters nil '((left .   0.0)))
 > (frame-geometry)
 >
 > => ((outer-position -20 . 188) (outer-size 1208 . 1226)
 >     (external-border-size 20 . 20) (outer-border-width . 0)
 >     (title-bar-size 0 . 70) (menu-bar-external . t) (menu-bar-size 1168
 >     . 24) (tool-bar-external . t) (tool-bar-position . top) (tool-bar-size
 >     1168 . 42) (internal-border-width . 0))
 >
 > The frame is visually flush with the left edge of the screen, but
 > frame-geometry claims itʼs at -20 ?

Is the left external border clearly visible?

 > For comparison, after toggle-frame-fullscreen
 >
 > ((outer-position 0 . 0) (outer-size 3840 . 2160) (external-border-size
 > 0 . 0) (outer-border-width . 0) (title-bar-size 0 . 0)
 > (menu-bar-external . t) (menu-bar-size 3840 . 24) (tool-bar-external
 > . t) (tool-bar-position . top) (tool-bar-size 3840 . 42)
 > (internal-border-width . 0))
 >
 > So is this the window manager lying to us? This is with XWayland, Iʼll
 > see if I can test under vanilla X.

A fullscreen frame usually doesn't have external borders.  Maximized
frames do but they are off-screen.  So these values seem normal to me.

martin

Re: modify-frame-parameters with floating point offsets

[Robert Pluim]

martin rudalics <rudalics@gmx.at> writes:

>> OK, is this normal?
>>
>> emacs -Q
>> (modify-frame-parameters nil '((left .   0.0)))
>> (frame-geometry)
>>
>> => ((outer-position -20 . 188) (outer-size 1208 . 1226)
>>     (external-border-size 20 . 20) (outer-border-width . 0)
>>     (title-bar-size 0 . 70) (menu-bar-external . t) (menu-bar-size 1168
>>     . 24) (tool-bar-external . t) (tool-bar-position . top) (tool-bar-size
>>     1168 . 42) (internal-border-width . 0))
>>
>> The frame is visually flush with the left edge of the screen, but
>> frame-geometry claims itʼs at -20 ?
>
> Is the left external border clearly visible?

No, the left external border is very small. Itʼs certainly not 20
pixels wide.

>> For comparison, after toggle-frame-fullscreen
>>
>> ((outer-position 0 . 0) (outer-size 3840 . 2160) (external-border-size
>> 0 . 0) (outer-border-width . 0) (title-bar-size 0 . 0)
>> (menu-bar-external . t) (menu-bar-size 3840 . 24) (tool-bar-external
>> . t) (tool-bar-position . top) (tool-bar-size 3840 . 42)
>> (internal-border-width . 0))
>>
>> So is this the window manager lying to us? This is with XWayland, Iʼll
>> see if I can test under vanilla X.
>
> A fullscreen frame usually doesn't have external borders.  Maximized
> frames do but they are off-screen.  So these values seem normal to me.

OK.

Robert

Re: modify-frame-parameters with floating point offsets

[martin rudalics]

 > No, the left external border is very small. Itʼs certainly not 20
 > pixels wide.

Then it's possible that your window manager tries to optimize things
in various ways without telling you the whole story.  I can imagine
that if an external border is usually 20 pixels wide, a window manager
might decide that showing the entire border on the edge of the display
is of no use and move the window to some negative position.  I would
dislike such behavior because it would make it virtually impossible to
orderly tile the screen.  In either case you would have to look at the
sources of your window manager to tell what it really does.

martin

Re: modify-frame-parameters with floating point offsets

[Robert Pluim]

martin rudalics <rudalics@gmx.at> writes:

>> No, the left external border is very small. Itʼs certainly not 20
>> pixels wide.
>
> Then it's possible that your window manager tries to optimize things
> in various ways without telling you the whole story.  I can imagine
> that if an external border is usually 20 pixels wide, a window manager
> might decide that showing the entire border on the edge of the display
> is of no use and move the window to some negative position.  I would
> dislike such behavior because it would make it virtually impossible to
> orderly tile the screen.  In either case you would have to look at the
> sources of your window manager to tell what it really does.

Whatever itʼs doing, gdk seems to have it figured out. Calling eg
gdk_window_get_frame_extents inside frame_geometry gets me values that
look much more sensible, whereas x_real_pos_and_offsets claims thereʼs
a 20 pixel border thatʼs simply not there visually.

Robert

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

[martin rudalics]

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

So we should try fixing (or documenting) the misbehavior of the (- n)
notation first.

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

I'm not sure I understand.  Do you mean that when you change the value
of 'left' the frame always stays within the left monitor while when
you change 'top' the frame moves from the upper to the lower monitor
and back?  That would be queer.

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

Hmm ... 2340 + 1480 gives 3820 which is obviously 20 pixels to the
left of 3840.  This clearly went wrong.  Did we _ask_ for 2340 or
2360?

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

Do we anywhere add only one 'external-border-size' instead of two?

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

Why did you ask for 2400 and not for 2360?  If the position value is
too large the window manager might try to fit the frame onto the
screen.  OTOH "correcting" this to 2380 means there are 20 pixels (the
full right external border) missing on the right if not I am missing
something.

BTW is this on a high resolution display?  Would/should we scale
external borders on such a display too?

martin

 > Iʼll take a look at x_calc_absolute_position.

Fine.

Thanks, martin

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

[Robert Pluim]

martin rudalics <rudalics@gmx.at> writes:

>>> 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)))
>
> So we should try fixing (or documenting) the misbehavior of the (- n)
> notation first.

As noted elsewhere, I think this is a window manager issue. Iʼd expect those
two calls to give the same effect, which is what I see.

>> 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.
>
> I'm not sure I understand.  Do you mean that when you change the value
> of 'left' the frame always stays within the left monitor while when
> you change 'top' the frame moves from the upper to the lower monitor
> and back?  That would be queer.

Iʼll have to retest this one, I may have missed a case.

>>>> [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)
>
> Hmm ... 2340 + 1480 gives 3820 which is obviously 20 pixels to the
> left of 3840.  This clearly went wrong.  Did we _ask_ for 2340 or
> 2360?

That I donʼt know, Iʼll find out...

>>    (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.
>
> Do we anywhere add only one 'external-border-size' instead of two?
>
>> 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.
>
> Why did you ask for 2400 and not for 2360?  If the position value is
> too large the window manager might try to fit the frame onto the
> screen.  OTOH "correcting" this to 2380 means there are 20 pixels (the
> full right external border) missing on the right if not I am missing
> something.

I asked for 2400 because if I ask for 2360 the frame is not flush
right.

> BTW is this on a high resolution display?  Would/should we scale
> external borders on such a display too?

Yes, itʼs high resolution, but 20 pixels seems like more than can be
accounted for by scaling.

> martin
>
>> Iʼll take a look at x_calc_absolute_position.

I think weʼre getting a -20 offset back from X somewhere when querying
the frame size/position. If I look at this hunk in
x_real_pos_and_offsets:

#ifdef USE_XCB
      geom = xcb_get_geometry_reply (xcb_conn, geom_cookie, NULL);
      if (geom)
	{
	  real_x = geom->x;

then real_x there is -20 when the frame is flush left. Should we be
using gdk/gtk calls to get the window geometry?

Robert

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

[martin rudalics]

 >> Why did you ask for 2400 and not for 2360?  If the position value is
 >> too large the window manager might try to fit the frame onto the
 >> screen.  OTOH "correcting" this to 2380 means there are 20 pixels (the
 >> full right external border) missing on the right if not I am missing
 >> something.
 >
 > I asked for 2400 because if I ask for 2360 the frame is not flush
 > right.

Funny.  There must be some strange calculations going on behind the
scenes.  Is there some consistency in the sense that your window
manager never shows the full external border when you want to place it
at some position on the left or top of the screen?

 > I think weʼre getting a -20 offset back from X somewhere when querying
 > the frame size/position.

And the -20 doesn't correspond to what you see on screen because the
external border is not fully visible.  Right?

 > If I look at this hunk in
 > x_real_pos_and_offsets:
 >
 > #ifdef USE_XCB
 >        geom = xcb_get_geometry_reply (xcb_conn, geom_cookie, NULL);
 >        if (geom)
 > 	{
 > 	  real_x = geom->x;
 >
 > then real_x there is -20 when the frame is flush left. Should we be
 > using gdk/gtk calls to get the window geometry?

By all means try to check whether these get you better results.  But
before that you might want to try disabling USE_XCB.  I recall an
earlier discussion where I strongly doubted the correctness of values
returned by x_real_pos_and_offsets.

martin

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

[Robert Pluim]

martin rudalics <rudalics@gmx.at> writes:

>>> Why did you ask for 2400 and not for 2360?  If the position value is
>>> too large the window manager might try to fit the frame onto the
>>> screen.  OTOH "correcting" this to 2380 means there are 20 pixels (the
>>> full right external border) missing on the right if not I am missing
>>> something.
>>
>> I asked for 2400 because if I ask for 2360 the frame is not flush
>> right.
>
> Funny.  There must be some strange calculations going on behind the
> scenes.  Is there some consistency in the sense that your window
> manager never shows the full external border when you want to place it
> at some position on the left or top of the screen?
>

No, I haven't noticed any artifacts like that.

>> I think weʼre getting a -20 offset back from X somewhere when querying
>> the frame size/position.
>
> And the -20 doesn't correspond to what you see on screen because the
> external border is not fully visible.  Right?
>

What there is of the external border is fully visible, since the frame
is not flush right (except when I ask for 2400, that is).

>> If I look at this hunk in
>> x_real_pos_and_offsets:
>>
>> #ifdef USE_XCB
>>        geom = xcb_get_geometry_reply (xcb_conn, geom_cookie, NULL);
>>        if (geom)
>> 	{
>> 	  real_x = geom->x;
>>
>> then real_x there is -20 when the frame is flush left. Should we be
>> using gdk/gtk calls to get the window geometry?
>
> By all means try to check whether these get you better results.  But
> before that you might want to try disabling USE_XCB.  I recall an
> earlier discussion where I strongly doubted the correctness of values
> returned by x_real_pos_and_offsets.

Some of them do seem bogus. disabling USE_XCB has no effect on the
values (I have a vague memory of Xlib using XCB behind the scenes now,
so thatʼs not too surprising)

Iʼll see if I can change the guts of x_real_pos_and_offsets to use
GDK directly, that might fix things.

Robert

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

[Robert Pluim]

Robert Pluim <rpluim@gmail.com> writes:

>>> 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.
>>
>> I'm not sure I understand.  Do you mean that when you change the value
>> of 'left' the frame always stays within the left monitor while when
>> you change 'top' the frame moves from the upper to the lower monitor
>> and back?  That would be queer.
>
> Iʼll have to retest this one, I may have missed a case.

Two monitors, one above the other, frame on bottom one.

(modify-frame-parameters nil '((top .   0.0)))
  => frame moves to top monitor
(modify-frame-parameters nil '((top .   1.0)))
  => frame moves tobottom monitor

Repeating those commands cycles between top and bottom monitor.

(and they're not flush to the edges, but this is with GDK scaling
going on, so Iʼm not too surprised by that).

Two monitors, one next to the other, frame on right one.

(modify-frame-parameters nil '((left .   0.0)))
  => frame moves to left monitor
(modify-frame-parameters nil '((left .   1.0)))
  => frame moves to right monitor

and again this cycles between the monitors. So whatever I tested
before, it wasn't this, and the behaviour is consistent between "left"
and "top".

I can't find anything in the elisp manual describing that the
workareas of the two monitors are combined like this.  Should such
information go in (elisp)Multiple Terminals, or (emacs)Multiple
Displays? Or both?

Robert

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

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Date: Fri, 06 Apr 2018 12:28:38 +0200
> Cc: 31031@debbugs.gnu.org
> 
> I can't find anything in the elisp manual describing that the
> workareas of the two monitors are combined like this.

AFAIK, this depends on how the monitors are configured, and perhaps
also on the window manager.  The "Multiple Terminals" node in ELisp
manual is what we felt we could document, and it does hint at what you
see, if you read the text carefully.

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

[Robert Pluim]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Robert Pluim <rpluim@gmail.com>
>> Date: Fri, 06 Apr 2018 12:28:38 +0200
>> Cc: 31031@debbugs.gnu.org
>> 
>> I can't find anything in the elisp manual describing that the
>> workareas of the two monitors are combined like this.
>
> AFAIK, this depends on how the monitors are configured, and perhaps
> also on the window manager.  The "Multiple Terminals" node in ELisp
> manual is what we felt we could document, and it does hint at what you
> see, if you read the text carefully.

I guess you mean this bit: "The third part, SCREENNUMBER, identifies a
zero-based screen number (a separate monitor) that is part of a single
monitor collection on that X server."

How about adding something like "Such a collection is often treated as
one bigger virtual screen." ?

Robert

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

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: 31031@debbugs.gnu.org
> Date: Fri, 06 Apr 2018 15:09:46 +0200
> 
> > AFAIK, this depends on how the monitors are configured, and perhaps
> > also on the window manager.  The "Multiple Terminals" node in ELisp
> > manual is what we felt we could document, and it does hint at what you
> > see, if you read the text carefully.
> 
> I guess you mean this bit: "The third part, SCREENNUMBER, identifies a
> zero-based screen number (a separate monitor) that is part of a single
> monitor collection on that X server."

Also, this:

     On some multi-monitor setups, a single X display outputs to more than
  one physical monitor.  You can use the functions
  ‘display-monitor-attributes-list’ and ‘frame-monitor-attributes’ to
  obtain information about such setups.

And this:

       ‘geometry’
	    Position of the top-left corner of the monitor’s screen and
	    its size, in pixels, as ‘(X Y WIDTH HEIGHT)’.  Note that, if
	    the monitor is not the primary monitor, some of the
	    coordinates might be negative.

> How about adding something like "Such a collection is often treated as
> one bigger virtual screen." ?

Sure, anything that might help understanding the issue without being
too definitive, provided that Martin is happy with the text.

Thanks.

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

[Drew Adams]

>  > Of course, the "out" is that it says, "In general, it is not a good idea
>  > to position a frame relative to the right or bottom edge of its
>  > display."  But the only case discussed in that context is an initial/new
>  > frame.
> 
> It also talks about how these positions are stored and restored, for
> example, when saving the desktop.

Yes.  But I'm not sure why you mention that here.
What might I be missing?

>  > And there is a similar caveat about using not using
>  > floating-point with decorated frames.  But again, it speaks only about
>  > "when CREATING decorated frames.
> 
> Because Emacs does not know the size of decorations _before_ a frame
> has been created.

Yes.  The case I'm asking about is the case of an existing frame.
I don't expect any magic for the new-frame case.  That part is
clear enough, I think.

>  > 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 have limited access to multiple monitors, myself.  The
manual says that the monitor that dominates a frame is
"the monitor that contains the largest part of the window"
((elisp) `Creating Frames').  And:

  A frame is “dominated” by a physical monitor when either the
  largest area of the frame resides in that monitor, or (if the frame
  does not intersect any physical monitors) that monitor is the
  closest to the frame.  Every (non-tooltip) frame (whether visible
  or not) in a graphical display is dominated by exactly one physical
  monitor at a time, though the frame can span multiple (or no)
  physical monitors.  -- (elisp) `Multiple Terminals'

>  > 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)))
>  > (modify-frame-parameters nil '((left . - 0.0)))
> 
> The last specification is wrong - floating point values must be
> unsigned.

Ah yes.  My bad.  The doc does say 0.0 to 1.0.
 
>  > (modify-frame-parameters nil '((left .   1.0)))
> 
> 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.

With a single monitor it does indeed do what you say, and
what one would expect.  When I tried with left and right
monitors I saw what I described (I don't have access to
multiple monitors today, but that is definitely what I
saw).

I'm guessing now that `modify-frame-parameters' pays no
attention to the dominating monitor and expects its
position inputs to always use screen coordinates, i.e.,
relative to all monitors combined, not relative to the
dominating monitor.

If so then the doc about floating-point perhaps just needs
to be modified to not talk about "display" (which can be,
at least in some other places, the dominating monitor),
and instead talk about "screen" (which seems to always
refer to the space of all monitors taken together.

>  > (And adding (user-position . t) changes nothing in this regard.)
> 
> 'user-position' has no effect on Windows and can be silently ignored
> by window managers on GNU/Linux.  Don't rely on it.

OK.  And the doc has generally made that clear.

However, this part of the doc this report is about is
unclear in this regard:

  If you want to be sure the position you specify is not
              ^^^^^^^^^^
  ignored, specify a non-‘nil’ value for the ‘user-position’
  parameter

That suggests that here, at least, the parameter makes sure
that you get what you ask for.

>  > What am I misunderstanding, here?  Can this text please be made more
>  > clear?  It's not really clear how floating-point values are supposed to
>  > be used or what they are supposed to do.  Dunno whether the behavior I'm
>  > seeing is bugged or the doc is wrong or I'm misunderstanding it.
> 
> Please state what you do not understand or can be improved in this
> text: [just a repeat of the existing doc]

See what I've said already.  I think it does not do what is
described, for multiple monitors. 

> In particular, it states that specifying floating point values is more
> suited for child frames than for normal frames although by design they
> should work for the latter too.

Yes, it says that.  And yes, I am using "decorated" frames.
But "they should work for the latter too" suggests that,
well, they should work for the latter too.

Don't get me wrong.  I appreciate the care with which you
wrote this doc (about floating-point values).  I think
perhaps it can be improved in two ways:

1. Corrected wrt mention of "display", if it is in fact
   the whole screen that is meant (e.g., in the case of
   multiple monitors.

2. The text is pretty dense.  This, in particular:

    A floating-point value ... specifies the
    left edge’s offset via the “left position ratio” of the
    frame—the ratio of the left edge of its outer frame to the
    width of the frame’s workarea (*note Multiple Terminals::) or
    its parent’s native frame (*note Child Frames::) minus the
    width of the outer frame.

Maybe split that sentence into at least two sentences, but
probably three or four (or five).

Maybe say "length of the left edge" instead of "left edge".

What's the "outer frame" in the case of a non-child frame?

Maybe say "screen area" instead of "frame's workarea"?  The
latter is undefined, AFAIK, and can suggest the dominating
monitor and not the total screen area of all monitors.

Maybe add "to" before "its parent's...", to make it more
clear that it's the ratio of the left-edge length to ___
or ___ (minus...), not the ratio of the left-edge length
or ___ to ___ (minus...).  But splitting the sentence up
into constituent pieces would help most.

Maybe each term used should be defined here, rather than
sending readers elsewhere.  If a reader has to go study
4 other dense nodes to understand the terms used here in
a super-dense spec, then there are too many obstacles to
understanding.

If you try to state the same info in multiple, very simple
sentences, then I can try to make suggestions that might
make that text flow better.  But without that starting
point of very simple statements I wouldn't really know
where to start.  (And probably the simple sentences would
be fine as is, with no further suggestions needed.)

HTH, and thanks for your work on this.  I'm hoping that
someone who has multiple monitors can chime in helpfully,
as well.

In sum, in priority, I'd suggest:

1. Possible code changes, to get the behavior consistent
   and understandable.

2. Factual changes to the doc to reflect that corrected
   behavior.

3. Simple sentences, defining terms (and possibly using
   diagrams) as needed, so the spec here is at least a
   bit more self-contained.

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

[martin rudalics]

 > Yes.  But I'm not sure why you mention that here.
 > What might I be missing?

Because the desktop restore algorithm cannot restore the originally
intended positioning, namely flushing the frame to the right whatever
the size of the display is.

 > I have limited access to multiple monitors, myself.  The
 > manual says that the monitor that dominates a frame is
 > "the monitor that contains the largest part of the window"
 > ((elisp) `Creating Frames').  And:
 >
 >    A frame is “dominated” by a physical monitor when either the
 >    largest area of the frame resides in that monitor, or (if the frame
 >    does not intersect any physical monitors) that monitor is the
 >    closest to the frame.  Every (non-tooltip) frame (whether visible
 >    or not) in a graphical display is dominated by exactly one physical
 >    monitor at a time, though the frame can span multiple (or no)
 >    physical monitors.  -- (elisp) `Multiple Terminals'

I read that text but since I have no experience with multiple monitors
I have no idea of its practical implications.

 > With a single monitor it does indeed do what you say, and
 > what one would expect.  When I tried with left and right
 > monitors I saw what I described (I don't have access to
 > multiple monitors today, but that is definitely what I
 > saw).

Robert's experience seems to confirm yours.

 > I'm guessing now that `modify-frame-parameters' pays no
 > attention to the dominating monitor and expects its
 > position inputs to always use screen coordinates, i.e.,
 > relative to all monitors combined, not relative to the
 > dominating monitor.

Maybe.  But then your problem should also show up when you try to
position the left or top position of your frame by giving the offset
of the left or top edge of the dominating monitor and that dominating
monitor is not the left-/top-most one.  Right?

 > If so then the doc about floating-point perhaps just needs
 > to be modified to not talk about "display" (which can be,
 > at least in some other places, the dominating monitor),
 > and instead talk about "screen" (which seems to always
 > refer to the space of all monitors taken together.

Maybe, again.  Is that display-screen dichotomy something we already
document somewhere?  If not we should fix the nomenclature first and I
have no good idea how to do that (in Emacs sources you will still find
places where the terms "frame" and "screen" are considered
equivalents).  So if there is some reasonable common understanding of
this matter, we should specify what the terms "screen", "display",
"monitor", "terminal" and "keyboard" stand for and how they relate to
each other.

 > However, this part of the doc this report is about is
 > unclear in this regard:
 >
 >    If you want to be sure the position you specify is not
 >                ^^^^^^^^^^
 >    ignored, specify a non-‘nil’ value for the ‘user-position’
 >    parameter
 >
 > That suggests that here, at least, the parameter makes sure
 > that you get what you ask for.

Ideally, yes.  But all too often the window manager might want to
correct that position to assure, for example, that a frame stays
completely on-screen.

 > 1. Corrected wrt mention of "display", if it is in fact
 >     the whole screen that is meant (e.g., in the case of
 >     multiple monitors.

I have to leave this part to someone who understands the implications
of the use of multiple monitors.

 > 2. The text is pretty dense.  This, in particular:
 >
 >      A floating-point value ... specifies the
 >      left edge’s offset via the “left position ratio” of the
 >      frame—the ratio of the left edge of its outer frame to the
 >      width of the frame’s workarea (*note Multiple Terminals::) or
 >      its parent’s native frame (*note Child Frames::) minus the
 >      width of the outer frame.
 >
 > Maybe split that sentence into at least two sentences, but
 > probably three or four (or five).
 >
 > Maybe say "length of the left edge" instead of "left edge".

These proposals are valuable.

 > What's the "outer frame" in the case of a non-child frame?

The "outer frame" is described in section 29.3.1 Frame Layout.

 > Maybe say "screen area" instead of "frame's workarea"?  The
 > latter is undefined, AFAIK, and can suggest the dominating
 > monitor and not the total screen area of all monitors.

We want to position a frame within its workarea to avoid that the
frame overlaps the windowing system's taskbar etc.

 > Maybe add "to" before "its parent's...", to make it more
 > clear that it's the ratio of the left-edge length to ___
 > or ___ (minus...), not the ratio of the left-edge length
 > or ___ to ___ (minus...).  But splitting the sentence up
 > into constituent pieces would help most.
 >
 > Maybe each term used should be defined here, rather than
 > sending readers elsewhere.  If a reader has to go study
 > 4 other dense nodes to understand the terms used here in
 > a super-dense spec, then there are too many obstacles to
 > understanding.

I understand your concerns but as you can see the "floating-point
value" entry is already much larger than the remaining ones and since
(if I understand Robert correctly) the "(- POS)" entry faces the same
problems wrt multiple monitors, we have to sort out this more general
problem anyway.

In either case, reading the Frame Geometry section will remain a
prerequsite for understanding some of the rest of the Frames chapter
in the Elisp manual.

martin