bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: martin rudalics
Subject: bug#24085: 25.1.50; `make-frame' given `top' param creates frame with ~10x smaller `top'
Date: Wed, 27 Jul 2016 11:19:54 +0200

> 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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]