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

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

>  > A user or code can (and should be able to) _move_ a frame to
>  > _any_ position, including partly or completely off screen.
> 
> Most window managers I know of refuse to make a new frame appear
> off screen on GNU/Linux.

1. What the window manager does is a different question, I think.

Parameter `user-position', for example, has doc that talks
about what a window manager might or might not do, including
perhaps not respecting `user-position' at all.

It is one thing if a window manager does not do what
`make-frame' specifies.  It is another thing if Emacs,
under the covers, silently, and without doc, does not do
what `make-frame' specifies.  No error, no return flag
indicating what was not taken into account, just behavior
that is different from what was specified, with no
acknowledgment of that difference.

2. I thought that the code change responsible for this
(intentional) regression was the one you cited from 2006,
and I thought that was only for MS Windows (w32term.c), so
I thought that change would not have any effect on other
platforms.

3. Refusing to create a frame that is completely off screen
is one thing.  Refusing to create a frame that is even slightly
off screen (e.g. echo area) is another thing.  Is the former or
the latter what you were referring to (by "most window
managers...")?  And in the case concerning MS Windows, IIUC,
it was about the echo area not being off screen necessarily,
but even just being hidden behind the task bar (which is on
screen).

But the main point I want to make here is #1: Emacs should at
least try to respect what `make-frame' specifies in a given
call.  If the window manager cannot respect that, that's a
separate problem, I think.  In that case perhaps Emacs can
raise an error, which a programmer could handle using
`condition-case' etc.  But Emacs should, I think, at least
try to DTRT, even if that might not always be possible.