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

[martin rudalics <rudalics@gmx.at>]

 > 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