bug#24085: 25.1.50; `make-frame' given `top' param creates frame with ~10x smaller `top'

[Drew Adams <drew.adams@oracle.com>]

> Due to this change:
> 2006-06-30  Ralf Angeli  <angeli@caeruleus.net>
> 
> 	* w32term.c (x_make_frame_visible): Use SystemParametersInfo with
> 	SPI_GETWORKAREA to find the dimensions of the screen work area,
> 	and adjust vertical position of the frame in order to avoid being
> 	covered by the taskbar.
> 
> See the thread starting at
> https://lists.gnu.org/archive/html/emacs-pretest-bug/2006-06/msg00142.html
> for the corresponding discussion.

Wow.  That's a revealing thread.  Thanks for finding it.

Such a large, and far-reaching (and bad) change resulting from so
little discussion, by only two people, who were apparently only
slightly annoyed by the _initial_ positioning of the initial
(startup) frame.

The thread is full of I-don't-know-whether-this-change-is-bad,
I'm-not-sure-if-make-frame-is-the-right-place,
maybe-we-should-not-do-this-if-top-is-explicitly-specified, etc.
That should have been a sign that something might be misguided here.

Would someone please revert this, and let `make-frame' respect the
frame parameters handed to it, in particular `top'?

I don't mind (I guess) if such fiddling is done only for the initial
frame.  The initial frame is anyway treated specially by Emacs.
That would be the right place for this hack, if a place there must be.

(But even for that I think that an explicit setting (e.g. in
`initial-frame-alist') should be respected.  And it does not make
a lot of sense to assume that the task bar is in the default
position, at the bottom of the screen.)

But as I say, I don't mind if such fiddling is done only for the
startup frame.  It should not be done for other frames.

`make-frame' is definitely the wrong place to do such fiddling.

A user or code can (and should be able to) _move_ a frame to
_any_ position, including partly or completely off screen.
I see no reason why `make-frame' should not, likewise, respect
`top', `left', etc.  And especially when (user-position . t)
is included!

(It's not even clear (predictable?) exactly what fudging is done.
You specify (top . 600) and you get something quite different
and unpredictable.)

Please, someone, reverse this (intentional) regression since
Emacs 21.  I haven't noticed it before because my own setup
uses a standalone minibuffer and sets up other frames.  I'm
now testing some code with emacs -Q, and I am really surprised
to see this behavior.

This "fix" does not really address the problem (hiding part of
the initial frame behind a Windows task bar) anyway, and it
shoots Emacs in the foot in a general way (`make-frame' is a
general, basic function).

Pretty please, can we remove this ball-&-chain from `make-frame'?
It should be a straightforward utility function, not some kind
of mysterious DWIM djinn.