On Wed, 29 Mar 2017 09:36:13 +0200, martin rudalics <rudalics@gmx.at>
wrote:
>> I have run your frame-position code a few times; I have not had time to
>> do
>  > anything else.
> 
> I suppose you did not (or were not able to) apply my patch so
> 
> (setq x-gtk-use-window-move t)
> 
> had not effect on the outcome of your runs.  Right?

That is correct; I want to try your change; I hope to get to it soon.

> 
>  > I am unable to do anything similar for 23.2 because
>  > function frame-position does not exist in 23.2.
> 
> I forgot.  Instead of
> 
> 	 (pos (frame-position frame))
> 	 (left (car pos))
> 	 (top (cdr pos))
> 
> use
> 
> 	 (left (frame-parameter frame 'left))
> 	 (top (frame-parameter frame 'top))
> 
> for Emacs 23.

I did not think that this would be important.  I attach a run for 23.2
this time.  FYI, it turns out that the code must be 
(id  (eval  (frame-parameter... in order to handle parameters such as (+
-9)

> 
>  > 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.
> 
> Your results for 25.1 are better than mine.  Here only the "arg" runs
> position correctly.  The "fun" and "par" frames all end up in the top
> left corner.  So if you do want to continue working with an unpatched
> Emacs 25.1 and want more or less correct positioning you will have to
> use the "arg" notation.  Otherwise you will have to either patch your
> 25.1 or switch to the current development version.
> 
> (
>   (arg
>    ...
>    (name . "4 Right Bottom")
>    (p-left . -40)
>    (p-top . -40)
>    (left . 1181)
>    (top . 694)
>    (width . 816)
>    (height . 400)
>    (r-left . -51)
>    (r-top . -58))
> 
> It might be interesting to see where these differences in the "arg" case
> come from - 11 pixels horizontally and 18 pixels vertically.  What does
> 
> M-: (frame-geometry)
> 
> in that frame return?

See Run 5 attached.

> 
> Thanks, martin