Same frame-positioning bug as before: negative top/left values on Windows

[Drew Adams]

This is an old bug. I thought this was going to be fixed by Fran's bug
fix, but I see that it is not. See my bug report of May 3, 2005, below.

emacs -q

In scratch buffer evaluate: (make-frame '((top . -1) (left . -1)))

The new frame does not have its bottom at the display bottom. The
frame bottom is below the frame bottom.

I've been waiting for this fix for a year and a half. I use a
standalone minibuffer frame, and I have code that positions it at the
display bottom, no matter the size of the display. The code works
perfectly in Emacs 20, but this bug causes the frame to be too low on
the display in Emacs 22(and since the frame is only two rows high,
it is essentially off the bottom of the display).

Can someone please fix this bug? Emacs should be able to correctly handle
negative `top' frame parameter values.

Thanks.

    -----Original Message-----
    From: address@hidden
    [mailto:address@hidden
    Behalf Of Francis Litterio
    Sent: Friday, July 08, 2005 5:30 PM
    To: address@hidden
    Cc: address@hidden
    Subject: [h-e-w] Re: Patch to fix frame positioning with negative
    top/leftvalues on Windows


    I wrote:

    > This patch to the CVS Emacs sources fixes the way that function
    > x_calc_absolute_position() accounts for the Windows-drawn
    borders around
    > a frame when converting a negative 'top or 'left parameter into the
    > equivalent positive value.

    I should have said what the symptom of the malfunction is that, on
    Windows, when you evaluate this Elisp code:

        (make-frame '((top . -1) (left . -1)))

    the new frame will not be positioned with its bottom-right corner in the
    bottom-right of the display.

    My patch fixes this, even in the case where the use configures
    non-standard vertical or horizontal frame border sizes.

    Sorry for the confusion.
    --
    Francis Litterio
    franl <at> world . std . com


    -----Original Message-----
    From: Drew Adams [mailto:address@hidden
    Sent: Tuesday, May 03, 2005 1:50 PM
    To: Francis Litterio; address@hidden
    Subject: RE: Patch to fix frame positioning bug on Windows with
    (make-frame '((left . -1)))


    I'm not sure if this is related to the thread below, but, in
    GNU Emacs 21.3.50.1 (i386-mingw-nt5.1.2600) of 2005-01-30 on
    NONIQPC, the positioning of a frame with `top' parameter = -14
    places the frame about 4 character-heights too low on the
    display. Instead of the bottom of the frame being 14 pixels
    above the display bottom, it appears to be about 28 pixels
    below the display bottom. My (frame-char-height) is 14. I'm on
    Windows XP.

    Thanks,

      Drew

        -----Original Message-----
        From: address@hidden

    [mailto:address@hidden Behalf Of
        Francis Litterio
        Sent: Wednesday, January 12, 2005 12:46 PM
        To: address@hidden
        Cc: address@hidden
        Subject: Re: Patch to fix frame positioning bug on Windows with
        (make-frame '((left . -1)))


        Jan D. wrote:

        >> Using Emacs built from CVS source code on Windows XP, the
        frame created
        >> using the following Emacs-Lisp code is positioned such that the
        >> rightmost 7 pixels of the frame are off the right edge
    of the screen:
        >>
        >>   (make-frame '((width . 80) (height . 20) (top . 0)
    (left . -1)))
        ...
        >> The below patch solves the problem but it may not be optimal
        because it
        >> simply subtracts 7 from the computed value of f->left_pos.
        >
        > Can you verify if your change has any impact on this bug:
        >
        >
        http://lists.gnu.org/archive/html/emacs-pretest-bug/2004-11/msg0
        0519.html
        >
        > This was the reason a change was made.  It may be
    impossible to get
        > Emacs to work correctly on W32.  Just [subtracting] 7 is
    no good, as
        > you self pointed out, a more general solution must be found.

        My change breaks the fix for that bug, so I'm going to investigate
        further.

        In my testing, I noticed that (make-frame '((top . -1))) on Windows
        suffers an even worse positioning error -- about 30 pixels
    at the bottom
        of the frame fall off the bottom of the screen!

        I would think that when a frame is positioned so that it is
    completely
        visible, we have the following variables and relations:

          OUTER-LEFT: The number of pixels between the left screen edge
                      and the left border drawn by Windows of the frame.
                      This can be 0.

          LEFT-BORDER: The width of the left border drawn by Windows
        (in pixels).

          FRAME-CONTENT-WIDTH: The width of the frame content, including
                               the fringes but not including the left and
                               right borders drawn by Windows.

          RIGHT-BORDER: The width of the right border drawn by Windows (in
                        pixels).

          OUTER-RIGHT: The number of pixels between the right screen edge
                       and the right border drawn by Windows of the frame.
                       This can be 0.

          DISPLAY-WIDTH: The width of the display (in pixels).

        and finally this relation should hold:

          DISPLAY-WIDTH = OUTER-LEFT + LEFT-BORDER + FRAME-CONTENT-WIDTH +
                          RIGHT-BORDER + OUTER-RIGHT

        A similar relation can be constructed for the vertical screen
        dimension.

        Given this model, we should be able to make w32term.c
    position frames
        consistently, regardless of whether the 'top or 'left frame
    parameter
        was positive or negative (modulo the issue with the user
    being able to
        change the width of the border drawn by Windows -- but it
    should work
        with Windows' default border sizes).

-------------------------

In GNU Emacs 22.0.50.1 (i386-mingw-nt5.1.2600)
 of 2006-06-29 on LE-DELLLAP
X server distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.2)'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: ENU
  locale-coding-system: cp1252
  default-enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  encoded-kbd-mode: t
  tooltip-mode: t
  tool-bar-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  auto-compression-mode: t
  line-number-mode: t

Recent input:
<down-mouse-1> <mouse-1> <help-echo> C-x b <return>
<down-mouse-1> <mouse-1> <down-mouse-2> <mouse-2> <help-echo>
<down-mouse-1> <mouse-1> C-x C-e <switch-frame> <switch-frame>
<switch-frame> <switch-frame> <switch-frame> <switch-frame>
<switch-frame> <switch-frame> <switch-frame> <switch-frame>
<switch-frame> <switch-frame> <switch-frame> <switch-frame>
<down-mouse-1> <mouse-1> <down-mouse-1> <mouse-1> <return>
<return> C-y <down-mouse-1> <mouse-1> C-x C-e <switch-frame>
<help-echo> <return> <return> C-y <down-mouse-1> <mouse-1>
C-x C-e <switch-frame> <switch-frame> <down-mouse-1>
<mouse-movement> <mouse-1> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<menu-bar> <help-menu> <report-emacs-bug>

Recent messages:
Loading dired...
Loading regexp-opt...done
Loading dired...done
Mark set
nil
Mark set
#<frame address@hidden 0x1b62800>
Mark set
#<frame address@hidden 0x299fa00>
Loading emacsbug...done