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

[Eli Zaretskii]

> Date: Wed, 27 Jul 2016 13:55:33 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: rudalics@gmx.at, 24085@debbugs.gnu.org
> 
> > The code in question is deep in
> > the low-level support for creating frames on Windows.  What it does is
> > make sure a frame, any frame, is not displayed with its echo area's
> > view obstructed by the task bar.
> 
> That's a mistake (misguided), I think.  Why was that the solution
> (or is the solution) to the problem reported, which was about the
> initial frame?

Because I think the issue exists not only for the initial frame.  See
the 10-year old discussion, it's all there.

> Can we not fix Emacs so that its avoidance of such positions is for
> the initial frame only?

I don't think this would be a step in the right direction.  Having a
frame obscured by window-system or window-manager decorations is a bad
screw that IMO we should try to avoid.

> Why should the behavior of a general function such as `make-frame'
> need to be sacrificed to fix that unique use case?

The solution wasn't intended to affect only the initial frame.  Once
again, please read the past discussion, as the implementation you see
now is not an accident, it was intended to do what you see.

> And if there _were_ a good reason for `make-frame' to avoid such
> positions in a general, default case (which I would disagree with,
> FWIW), why would that be the case also for the non-default cases
> where you pass an explicit PARAMETERS list to `make-frame'?  Surely,
> at least in that case the coder's intention should be respected.
> And a fortiori if (user-position . t) is in PARAMETERS.  I cannot
> see any argument for _never_ being able to have `make-frame' respect
> PARAMETERS.

This could be an idea worth considering, although I'm not necessarily
sure it's the best or even a right one.  Patches and discussion are
welcome.

> I think (hope) you are saying that there is no good argument for
> not respecting PARAMETERS, but because of the previous, low-level fix,
> that's unfortunately where we are today.  In that case, let's please
> try to do better.  If `set-frame-parameter' can in a sense "override"
> or work around that low-level dictation of frame positioning, then
> I imagine it should be possible for `make-frame' to do the same.

The problem is not only technical, it's also a problem of our intent.
Do we _want_ to let frames have their echo area obscured?  If not,
then the fact that set-frame-parameter allows that would be a bug that
needs to be fixed.  Also, what happens on other window-systems?
Martin says most GNU/Linux window managers will behave the same as
Emacs on Windows behaves now.

> > You put in my mouth things I didn't say.
> 
> I'm glad to hear that, and I apologize if I misunderstood you.
> It must be said that you did not say much - hardly much to go on,
> to decipher your meaning or intention.

What I wrote was very clear, and didn't need any deciphering:
reverting that change is out of the question.  No more, no less.

> Anyway, I take it now that you will seriously consider trying to
> fix this problem for `make-frame'?

Did I ever say I won't?  Why would you even consider such a ridiculous
(to say the least) possibility?

> I'll say again that this is not something that annoys me in my own
> use of Emacs, in general.

It basically annoys no one, since the change was made 10 years ago,
and we had no complaints.  One more factor to consider while
discussing this issue, I guess.

> Since I have your attention, and if it doesn't take too much of
> your time, could you or Martin perhaps please recommend a way of
> getting the screen-relative pixel coordinates of a given buffer
> position in a given window of a given Emacs frame?

This is not the place to ask such question, so I will respond on
emacs-devel.  Please everybody, don't continue this sub-thread here.