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

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

[Drew Adams]

emacs -Q

In *scratch*, type and evaluate:

(make-frame '((name . "AAA")
              (left . 800) (top . 600)
              (user-position . t)))

In the new frame, do `M-: (frame-parameters)'.  You see something like
this:

((tool-bar-position . top) (parent-id) (explicit-name . t)
 (display . "w32") (visibility . t) (icon-name) (window-id . "265868")
 (top . 73) (left . 800) (buried-buffer-list)
 ^^^^^^^^^^ ^^^^^^^^^^^^
 (buffer-list #<buffer *scratch*> #<buffer  *Minibuf-1*>)
 (unsplittable) ...)

And that new frame is indeed about 73 pixels from the top screen edge,
and about 800 pixels from the left screen edge.

What am I missing?  The Elisp manual, node `Position Parameters' seems
to say that `top' is just like `left'.  The resulting `left' value is
exactly what was prescribed to `make-frame', but the resulting `top'
value is 73 instead of the prescribed 600.

But I see about the same behavior in Emacs 23 and 22, so this is
apparently not new.  Am I misunderstanding the doc description?

FWIW, Emacs 20 behaves just like the doc says (as I understand it): the
resulting `top' value is exactly what you provide to `make-frame', and
the frame is actually positioned with its top at that position (not at
a top location that is ~10x smaller).


In GNU Emacs 25.1.50.1 (i686-pc-mingw32)
 of 2015-12-10
Repository revision: 6148555ee5a3d0139ae517803718b3e0357933c7
Windowing system distributor 'Microsoft Corp.', version 6.1.7601
Configured using:
 'configure --prefix=/c/Devel/emacs/snapshot/trunk --enable-checking=yes
 --enable-check-lisp-object-type --without-compress-install 'CFLAGS=-Og
 -ggdb3' LDFLAGS=-Lc:/Devel/emacs/lib 'CPPFLAGS=-DGC_MCHECK=1
 -Ic:/Devel/emacs/include''

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

[martin rudalics]

 > emacs -Q
 >
 > In *scratch*, type and evaluate:
 >
 > (make-frame '((name . "AAA")
 >                (left . 800) (top . 600)
 >                (user-position . t)))
 >
 > In the new frame, do `M-: (frame-parameters)'.  You see something like
 > this:
 >
 > ((tool-bar-position . top) (parent-id) (explicit-name . t)
 >   (display . "w32") (visibility . t) (icon-name) (window-id . "265868")
 >   (top . 73) (left . 800) (buried-buffer-list)
 >   ^^^^^^^^^^ ^^^^^^^^^^^^
 >   (buffer-list #<buffer *scratch*> #<buffer  *Minibuf-1*>)
 >   (unsplittable) ...)
 >
 > And that new frame is indeed about 73 pixels from the top screen edge,
 > and about 800 pixels from the left screen edge.
 >
 > What am I missing?  The Elisp manual, node `Position Parameters' seems
 > to say that `top' is just like `left'.  The resulting `left' value is
 > exactly what was prescribed to `make-frame', but the resulting `top'
 > value is 73 instead of the prescribed 600.
 >
 > But I see about the same behavior in Emacs 23 and 22, so this is
 > apparently not new.  Am I misunderstanding the doc description?
 >
 > FWIW, Emacs 20 behaves just like the doc says (as I understand it): the
 > resulting `top' value is exactly what you provide to `make-frame', and
 > the frame is actually positioned with its top at that position (not at
 > a top location that is ~10x smaller).

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.

martin

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

[Drew Adams]

> 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.

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

[Eli Zaretskii]

> Date: Wed, 27 Jul 2016 06:29:14 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> 
> Would someone please revert this, and let `make-frame' respect the
> frame parameters handed to it, in particular `top'?

Not a chance, sorry.

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

[martin rudalics]

 > 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.

martin

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

[Eli Zaretskii]

> Date: Thu, 28 Jul 2016 10:57:24 +0200
> From: martin rudalics <rudalics@gmx.at>
> 
>  > 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.

Do they also refuse to move a frame so that part of it is off the
screen?  Or is the above only enforced for the initial location of the
frame?

Thanks.

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

[martin rudalics]

 > Do they also refuse to move a frame so that part of it is off the
 > screen?  Or is the above only enforced for the initial location of the
 > frame?

Only for the initial location of the frame.  After that you can move the
frame off screen.

martin

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

[Drew Adams]

>  > 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.

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

[martin rudalics]

 > 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.

There was no need.  The behavior on GNU/Linux preceded that on MS
Windows.  I can't tell about the behavior on other systems.

 > 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...")?

Here xfce positions the frame exactly like Windows does, right above the
taskbar.  I have no idea whether this similarity was intentional.

martin

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

[Lars Ingebrigtsen]

Skimming this bug report, it seems the conclusion was that we don't want
to change anything here, and that the user can use `set-frame-position'
to move the frame around to a more precise location (which is what you
have to do in many window managers anyway, because they refuse to create
frames that are partially off-screen).  So I'm closing the bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Drew Adams]

> Skimming this bug report, it seems the conclusion was that we don't
> want to change anything here, and that the user can use `set-frame-position'
> to move the frame around to a more precise location (which is what you
> have to do in many window managers anyway, because they refuse to
> create frames that are partially off-screen).  So I'm closing the bug report.

Too bad.
So much for your skimming.  `set-frame-position'
isn't even mentioned in the bug thread - not once.

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

[Drew Adams]

> > Would someone please revert this, and let `make-frame' respect the
> > frame parameters handed to it, in particular `top'?
> 
> Not a chance, sorry.

Huh? What's that all about?

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

[Eli Zaretskii]

> Date: Wed, 27 Jul 2016 09:57:44 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: rudalics@gmx.at, 24085@debbugs.gnu.org
> 
> > > Would someone please revert this, and let `make-frame' respect the
> > > frame parameters handed to it, in particular `top'?
> > 
> > Not a chance, sorry.
> 
> Huh? What's that all about?

Reverting the change will reintroduce the bug it fixed, so doing that
is out of the question.

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

[Drew Adams]

> > > > Would someone please revert this, and let `make-frame' respect the
> > > > frame parameters handed to it, in particular `top'?
> > >
> > > Not a chance, sorry.
> >
> > Huh? What's that all about?
> 
> Reverting the change will reintroduce the bug it fixed

Obviously, as I indicated in my earlier message, I meant that the
bug that it fixed should be fixed properly, without treading on
`make-frame'.  If on MS Windows you think the first Emacs frame
should be positioned so that it does not overlap the task bar,
then do that.  But do it without affecting what `make-frame' does.

> so doing that is out of the question.

What _is_ in the question, then?  If you are unwilling to fix the
code, will you fix the doc?

Will you update the doc to say that `make-frame' does not (or might
not, or does not in the following cases...) respect this and that
parameter (whichever parameters it does not respect)?

Will you tell users in the doc that if they want (this or that part
of) the PARAMETERS argument to have any effect they will need to call
`set-frame-parameter' after `make-frame', to set those parameters as
they expected `make-frame' would have done?  IOW, PARAMETERS, or at
least some of it, might have no effect, so users had better find
some other way to set the frame parameters?

I find your reaction here to be dismissive and overreactive, so far.

Just what bug did this change seek to fix?  Wasn't it only the default,
initial behavior of Emacs for the initial frame?  If so, how is this
general change to `make-frame' the right fix for that bug?

And how would it hurt for `make-frame' to at least respect an _explicit_
frame alist argument, which is, after all, optional?  Why does it have
such an argument, if it no longer respects it?

It seems to me that a proper fix for the problem described in the
bug report that this "fix" was for is to do something specific for
the initial Emacs frame only - which is _anyway_ special-cased.  Take
some code from the existing `make-frame' and give it another name for
that special case, for example.

But why take over the single, general-purpose frame-creation Lisp
function we have, changing its behavior to ignore parts of optional
arg PARAMETERS (on one platform, no less), just to accommodate the
special case of the initial frame?

This makes no sense to me.  And I find it hard to believe that you
would not consider fixing that bug properly and restoring `make-frame'
to a general-purpose function that respects whatever optional frame
parameters are specified.

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

[Eli Zaretskii]

> Date: Wed, 27 Jul 2016 11:39:49 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: rudalics@gmx.at, 24085@debbugs.gnu.org
> 
> > > > > Would someone please revert this, and let `make-frame' respect the
> > > > > frame parameters handed to it, in particular `top'?
> > > >
> > > > Not a chance, sorry.
> > >
> > > Huh? What's that all about?
> > 
> > Reverting the change will reintroduce the bug it fixed
> 
> Obviously, as I indicated in my earlier message, I meant that the
> bug that it fixed should be fixed properly, without treading on
> `make-frame'.  If on MS Windows you think the first Emacs frame
> should be positioned so that it does not overlap the task bar,
> then do that.  But do it without affecting what `make-frame' does.
> 
> > so doing that is out of the question.
> 
> What _is_ in the question, then?

Anything else.

> If you are unwilling to fix the code, will you fix the doc?

If that's the best we can do, yes.

> Just what bug did this change seek to fix?  Wasn't it only the default,
> initial behavior of Emacs for the initial frame?  If so, how is this
> general change to `make-frame' the right fix for that bug?

Please re-read the discussion, the answers are there.

> And how would it hurt for `make-frame' to at least respect an _explicit_
> frame alist argument, which is, after all, optional?  Why does it have
> such an argument, if it no longer respects it?

The code that bothers you is not in make-frame.

> But why take over the single, general-purpose frame-creation Lisp
> function we have, changing its behavior to ignore parts of optional
> arg PARAMETERS (on one platform, no less), just to accommodate the
> special case of the initial frame?

No one took over any Lisp function.  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.

> This makes no sense to me.  And I find it hard to believe that you
> would not consider fixing that bug properly and restoring `make-frame'
> to a general-purpose function that respects whatever optional frame
> parameters are specified.

You put in my mouth things I didn't say.

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

[Drew Adams]

> > > Reverting the change will reintroduce the bug it fixed
> >
> > Obviously, as I indicated in my earlier message, I meant that the
> > bug that it fixed should be fixed properly, without treading on
> > `make-frame'.  If on MS Windows you think the first Emacs frame
> > should be positioned so that it does not overlap the task bar,
> > then do that.  But do it without affecting what `make-frame' does.
> >
> > > so doing that is out of the question.
> >
> > What _is_ in the question, then?
> 
> Anything else.

Good!

> > If you are unwilling to fix the code, will you fix the doc?
> 
> If that's the best we can do, yes.

Also good - better than nothing.

> > Just what bug did this change seek to fix?  Wasn't it only the default,
> > initial behavior of Emacs for the initial frame?  If so, how is this
> > general change to `make-frame' the right fix for that bug?
> 
> Please re-read the discussion, the answers are there.
> 
> > And how would it hurt for `make-frame' to at least respect an _explicit_
> > frame alist argument, which is, after all, optional?  Why does it have
> > such an argument, if it no longer respects it?
> 
> The code that bothers you is not in make-frame.

What bothers me is the effect on `make-frame', regardless of where
the culprit code may be.

> > But why take over the single, general-purpose frame-creation Lisp
> > function we have, changing its behavior to ignore parts of optional
> > arg PARAMETERS (on one platform, no less), just to accommodate the
> > special case of the initial frame?
> 
> No one took over any Lisp function.

The behavior of `make-frame' (this bug) was altered drastically, so
that its optional PARAMETERS argument is at best problematic, and at
worst nearly useless.  The intention of the fix might not have been
to do that, but that was the effect on `make-frame', which is what
this bug report is about.

> 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?

As I said, it is entirely possible (and thank goodness) for either a
user or Lisp code to _move_ a frame into positions that you want to
avoid for the initial frame.  Not just positions that don't show the
echo area, but positions that can place any part - or all - of a frame
off screen. 

Can we not fix Emacs so that its avoidance of such positions is for
the initial frame only?  And if we can, let's please do that.  The
initial-frame case is a special (unique) case in this and other ways.
Why should the behavior of a general function such as `make-frame'
need to be sacrificed to fix that unique use case?

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.

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.

If nothing else, if PARAMETERS is present, shouldn't `make-frame' be
able to at least update the frame parameters, respecting PARAMETERS,
immediately after the low-level code creates it in the (wrong) position
that it uses to avoid hiding the echo area?

> > This makes no sense to me.  And I find it hard to believe that you
> > would not consider fixing that bug properly and restoring `make-frame'
> > to a general-purpose function that respects whatever optional frame
> > parameters are specified.
> 
> 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.

Anyway, I take it now that you will seriously consider trying to
fix this problem for `make-frame'?  That would be great, and all
that anyone could ask.

I'll say again that this is not something that annoys me in my own
use of Emacs, in general.  I stumbled on it now, with emacs -Q,
after it having been introduced 10 years ago apparently.  But I
think that Emacs's `make-frame' should behave as it did before,
even if something should be done to ensure that the initial frame
is not occluded.

---

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?

I've been fiddling a bit with test code like this, but haven't
really found anything reasonable yet:

;; Try to get screen-relative X, Y (pixels) for current point
(let* ((posn-at-pt  (posn-at-point))
       (x-y         (and posn-at-pt  (posn-x-y posn-at-pt)))
       (win-edges   (and x-y  (window-inside-absolute-pixel-edges)))
	(x           (and x-y  (+ (car x-y) (car win-edges))))
	(y           (and x-y  (+ (cdr x-y) (cadr win-edges))))
	(y           (and y  (top-fudge-pixels y))))
  ...)

(defun top-fudge-pixels (y)
  (let ((y2  y))
    (when tool-bar-mode (setq y2  (+ 40 tp)))
    (when menu-bar-mode (setq y2  (+ 25 tp)))
    (setq y2  (+ y2 28))  ; Frame title bar
    y2))

Just hoping I'm missing something simple, like a function
`screen-relative-x-y-pixels-at-point'...  Thanks, if you can
point the way.

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

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 5918 bytes --]

On 2016-07-27 16:55, Drew Adams wrote:
> Just hoping I'm missing something simple, like a function
> `screen-relative-x-y-pixels-at-point'...  Thanks, if you can
> point the way.

Hey Drew,

There was a discussion about this on the Wiki page for pos-tip (back then you suggested filing an enhancement request). The following function, from pos-tip.el, seems to do more or less what you're looking for. Does it? I'm not sure how well it works in Windows.

In any case, it would be nice if this was easily feasible.

Cheers,
Clément.

(defun pos-tip-compute-pixel-position
  (&optional pos window pixel-width pixel-height frame-coordinates dx dy)
  "Return pixel position of POS in WINDOW like (X . Y), which indicates
the absolute or relative coordinates of bottom left corner of the object.

Omitting POS and WINDOW means use current position and selected window,
respectively.

If PIXEL-WIDTH and PIXEL-HEIGHT are given, this function assumes these
values as the size of small window like tooltip which is located around the
object at POS. These values are used to adjust the location in order that
the tooltip won't disappear by sticking out of the display. By referring
the variable `pos-tip-upperside-p' after calling this function, user can
examine whether the tooltip will be located above the specified position.

If FRAME-COORDINATES is omitted or nil, automatically obtain the absolute
coordinates of the top left corner of frame which WINDOW is on. Here,
`top left corner of frame' represents the origin of `window-pixel-edges'
and its coordinates are essential for calculating the return value as
absolute coordinates. If a cons cell like (LEFT . TOP), specifies the
frame absolute location and makes the calculation slightly faster, but can
be used only when it's clear that frame is in the specified position. Users
can get the latest values of frame coordinates for using in the next call
by referring the variable `pos-tip-saved-frame-coordinates' just after
calling this function. Otherwise, FRAME-COORDINATES `relative' means return
pixel coordinates of the object relative to the top left corner of the frame.
This is the same effect as `pos-tip-use-relative-coordinates' is non-nil.

DX specifies horizontal offset in pixel.

DY specifies vertical offset in pixel. This makes the calculations done
without considering the height of object at POS, so the object might be
hidden by the tooltip."
  (let* ((frame (window-frame (or window (selected-window))))
	 (w32-frame (eq (pos-tip-window-system frame) 'w32))
	 (relative (or pos-tip-use-relative-coordinates
		       (eq frame-coordinates 'relative)
		       (and w32-frame
			    (null pos-tip-w32-saved-max-width-height))))
	 (frame-coord (or (and relative '(0 . 0))
			  frame-coordinates
			  (pos-tip-frame-top-left-coordinates frame)
			  (progn
			    (setq relative t
				  pos-tip-use-relative-coordinates t)
			  '(0 . 0))))
	 (posn (posn-at-point (or pos (window-point window)) window))
	 (line (cdr (posn-actual-col-row posn)))
	 (line-height (and line
			   (or (window-line-height line window)
			       (and (redisplay t)
				    (window-line-height line window)))))
	 (x-y (or (posn-x-y posn)
		  (let ((geom (pos-visible-in-window-p
			       (or pos (window-point window)) window t)))
		    (and geom (cons (car geom) (cadr geom))))
		  '(0 . 0)))
	 (x (+ (car frame-coord)
	       (car (window-inside-pixel-edges window))
	       (car x-y)
	       (or dx 0)))
	 (y0 (+ (cdr frame-coord)
		(cadr (window-pixel-edges window))
		(or (nth 2 line-height) (cdr x-y))))
	 (y (+ y0
	       (or dy
		   (car line-height)
		   (with-current-buffer (window-buffer window)
		     (cond
		      ;; `posn-object-width-height' returns an incorrect value
		      ;; when the header line is displayed (Emacs bug #4426).
		      ((and posn
			    (null header-line-format))
		       (cdr (posn-object-width-height posn)))
		      ((and (bound-and-true-p text-scale-mode)
			    (not (zerop (with-no-warnings
					  text-scale-mode-amount))))
		       (round (* (frame-char-height frame)
				 (with-no-warnings
				   (expt text-scale-mode-step
					 text-scale-mode-amount)))))
		      (t
		       (frame-char-height frame)))))))
	 xmax ymax)
    (cond
     (relative
      (setq xmax (frame-pixel-width frame)
	    ymax (frame-pixel-height frame)))
     (w32-frame
      (setq xmax (car pos-tip-w32-saved-max-width-height)
	    ymax (cdr pos-tip-w32-saved-max-width-height)))
     (t
      (setq xmax (x-display-pixel-width frame)
	    ymax (x-display-pixel-height frame))))
    (setq pos-tip-upperside-p (> (+ y (or pixel-height 0))
				 ymax))
    (cons (max 0 (min x (- xmax (or pixel-width 0))))
	  (max 0 (if pos-tip-upperside-p
		     (- (if dy ymax y0) (or pixel-height 0))
		   y)))))


(defun pos-tip-w32-max-width-height (&optional keep-maximize)
  "Maximize the currently selected frame temporarily and set
`pos-tip-w32-saved-max-width-height' the effective display size in order
to become possible to calculate the absolute location of tooltip.

KEEP-MAXIMIZE non-nil means leave the frame maximized.

Note that this function is usable only in Emacs 23 for MS-Windows."
  (interactive)
  (unless (eq window-system 'w32)
    (error "`pos-tip-w32-max-width-height' can be used only in w32 frame."))
  ;; Maximize frame
  (with-no-warnings (w32-send-sys-command 61488))
  (sit-for 0)
  (let ((offset (pos-tip-calibrate-frame-offset)))
    (prog1
	(setq pos-tip-w32-saved-max-width-height
	      (cons (frame-pixel-width)
		    (+ (frame-pixel-height)
		       (- (cdr offset) (car offset)))))
      (if (called-interactively-p 'interactive)
	  (message "%S" pos-tip-w32-saved-max-width-height))
      (unless keep-maximize
	;; Restore frame
	(with-no-warnings (w32-send-sys-command 61728))))))


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Drew Adams]

Hi Clément,

Thanks for reminding me of that pos-tip thread, which I found here:
https://www.emacswiki.org/emacs/PosTip.  And thanks for posting a
possible solution.  I'll take a look at it.

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

[martin rudalics]

 > 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?

With Emacs 25 you can combine ‘pos-visible-in-window-p’ with
‘window-absolute-body-pixel-edges’.

martin

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

[Drew Adams]

>  > 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?
> 
> With Emacs 25 you can combine ‘pos-visible-in-window-p’ with
> ‘window-absolute-body-pixel-edges’.

Thanks.  It's not clear to me how `pos-visible-in-window-p'
would enter the picture (except to confirm that a position
is visible before asking for its pixel coordinates, and for
`point' that is always the case), but I guess I can see how
`window-absolute-body-pixel-edges' might help.

---

Unfortunately for me, I cannot use anything from Emacs 25,
as it is hopelessly broken, so far, at least in my context.
At this point I can only hope that someone else eventually
reports problems similar to those I've reported (e.g. crashes)
and has better luck than I in tracking down the causes and
getting them fixed.

But I continue to follow Emacs development, and I continue 
to try new builds of 25, just in case.  (I make no claim that
my case is typical, obviously.)

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.

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

[Drew Adams]

> > 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?

I certainly do.  I have commands that rely on it, including commands
that incrementally move frames around (e.g., holding a key pressed moves
a frame right, left, up, or down, incrementally), and they wrap around
the display or from one monitor to another.

And a frame does not necessarily even have an echo area. None of my
frames do, apart from my standalone minibuffer frame.

Basic Emacs functions should not be DWIM.  A user or code should
definitely be able to position a frame anywhere.  Similarly, we have
the ability to make frames invisible.  Would you take that away, using
as argument that a user cannot see the echo area on such a frame?

> If not, then the fact that set-frame-parameter allows that would be
> a bug that needs to be fixed.

Sheesh.  Maybe I'd better stop filing bug reports, if when I do so it
encourages you to remove some other longstanding Emacs feature I use.