Hello Martin,

I have run your frame-position code a few times; I have not had time to do
anything else.

GNU Emacs 25.1.3 (x86_64-unknown-linux-gnu, GTK+ Version 3.18.9) of
2017-03-19
Linux Mint 18.1 Serena (GNU/Linux 4.4.0-53-generic x86_64)

The screenshots show the result of running your code under both 23.2 and
25.1.  As you can see, 23.2 produced the four stacks of three frames as
expected.  Also clear is that three of the four stacks under 25.1 are not
even: there is positional scatter.  What is not clear is that the 25.1
stacks do not always have three frames each.

I modified your code to help me look at what was happening, this code is
attached.  I ran both sets of code several times.  The results are
interesting because the behaviour usually changed from run to run; in
other words the code is not deterministic.

The attached file list-output-unmodified shows output from a 25.1 run that
had 5 frames in the left top corner, 3 frames in the right bottom corner,
and 2 in each of the other corners.  I emphasize that these stack sizes
are not consistent.  I am unable to do anything similar for 23.2 because
function frame-position does not exist in 23.2.

The modified code labels the frames and so it is possible to see which are
the rogue frames in any given run.  A correct run gives the result below,
and it is easy to see how this is correct since 1-4 are the arg frames,
5-8 are par, 9-C are fun, and the position order is LT, LB, RT, RB.  The
9-C frames are on top of the stack, so they are the first that are seen.
LT 951            RT B73
LB A62            RB C84

Here are some results from other runs:
   9651              B73    see list-output-1
   A2                 C84

   BA987651          3    see list-output-2
   2                     C4

   9651              B73
   A2                 C84

   987651            B3
   A2                   C4

Mostly, but not always, the 9-C (fun) frames are consistently in their
correct corner.  This is true for the 1-4 (arg) frames as well; I do not
have any record of a deviation, so arg frames may be perfect.  The 5-8
(par) frames are the deviants, which seem to go the the Left Top corner.

I hope that this helps.  I shall do more as soon as I have time.

David


On Thu, 23 Mar 2017 08:59:49 +0100, martin rudalics <rudalics@gmx.at>
wrote:
>> I'll eventually push a "fix" to the repository but this
>  > will certainly not become part of the Emacs 25 series.
> 
> I've pushed a fix to master now.  So if you can work with master please
> update your copy and set, in your init file, the variable
> `x-gtk-use-window-move' to t and see whether your problem one is fixed
> now.
> 
> To everyone who sets negative frame positions in her programs or init
> file: Please try loading the attached file frame-position.el, evaluate
> it, call `frame-position-make' which will create twelve frames evenly
> distributed among the corners of your screen and finally run the
> function `frame-position-list' whose return value lists position and
> size information about these frames.  Here this gets me a list like
> 
> ((display-pixel-width . 1680)
>   (display-pixel-height . 1050)
>   (arg
>    (p-left . 40)
>    (p-top . 40)
>    (left . 40)
>    (top . 40)
>    (width . 750)
>    (height . 360))
>    ...
> (arg
>    (p-left . -40)
>    (p-top . -40)
>    (left . 904)
>    (top . 564)
>    (width . 750)
>    (height . 360)
>    (r-left . -26)
>    (r-top . -126))
>    ...
>   (fun
>    (p-left . -40)
>    (p-top . -40)
>    (left . 890)
>    (top . 564)
>    (width . 750)
>    (height . 360)
>    (r-left . -40)
>    (r-top . -126)))
> 
> The "arg" frames were produced by supplying sizes and positions via the
> argument list of `make-frame'.  The "par" frames were produced by
> calling `modify-frame-parameters' with the sizes and positions after the
> frame was made and making the frame visible after that.  The "fun"
> frames were produced by setting frame sizes and positions after the
> frame was made and making the frame visible after that.
> 
> p-left stands for the programmed and r-left for the realized left
> position.  p-top and r-top do that for the top position.  Ideally, these
> values are the same, often they aren't.  Here, the difference between
> the "arg" and the "fun" values is that the latter apparently already
> counts in 14 pixels for the scroll bar.
> 
> Besides that, the values are still far from correct on GNU/Linux since
> they do not account for the window manager decorations.  I would be
> interested if people get results that differ from the examples I gave
> above.
> 
> Thanks, martin