RE: Emacs geometry

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

    > From: "Drew Adams" <drew.adams@oracle.com>
    > I reported this bug recently to Fran Litterio.

    What bug, and in which message did you report it?

As I said, I reported it to Fran, as at first I thought it was related to
his fix of another frame positioning bug I reported. Here is most of what I
sent to Fran, followed by my view of this new behavior and a request to put
things back the way they were.

----

With emacs -Q:

The initial frame is 2 or 3 cm from the upper left of the display (more or
less like what happens if you do (set-frame-position (selected-frame) 100
100)); in the past, the initial frame has always been flush with top left.

Playing with `make-frame' a little, I'm convinced that that is the problem,
but I don't quite understand what's going on. It seems to open frames in
different places, not necessarily with regard to standard "cascading" (to
the right and down) from the current frame.

I'm not sure that the position of a frame created by `make-frame' is
specified by Emacs, if you don't supply a frame alist, but the behavior
seems wrong now generally, and it is quite different from the behavior
before. It also seems inconsistent now, and it was consistent before.

In my own code (not emacs -Q, which was the case for the above description),
here are 1) the alist I pass to `make-frame' to create a standalone
minibuffer frame and 2) my value of `default-frame-alist'.

Minbuffer:

(...
 (menu-bar-lines)
 (height . 2)
 (icon-type . t)
 (minibuffer . only)
 (user-position . t)
 (vertical-scroll-bars))

`default-frame-alist':

(...
 (menu-bar-lines . 1)
 (top . 0)
 (left . 0)
 (width . 80)
 (height . 35)
 (minibuffer)
 (user-position . t)
 (tool-bar-lines . 1)
 (left-fringe . 0)
 (right-fringe . 0)
 (fringe . 0)
 (menu-bar-lines . 1))

I don't impose a top, left position for the minibuffer frame using the
alist; I position that frame afterward, using `modify-frame-parameters'.

I do impose (0, 0) as the position of default-frame-alist. Nevertheless, the
first frame created is maybe 4cm from the left and 5cm from the top (and the
minibuffer frame is about 1cm from the left). So, the default-frame-alist
does not seem to be respected, wrt position.

Actually, it's weirder than that. The initial positions of the main frame
and the minibuffer frame seem to be inconsistent. At first I thought it
might depend on which other frames were open - even from a different Emacs
session. I iconified some existing sessions and then started a new Emacs
session, and the main frame was about 2cm from the left and 3cm from the
top; the minibuffer frame was about 3cm from the left. But I did that again,
and the positions were 2cm, 3cm for the main frame and 5cm for the
minibuffer frame. It's almost as if the last position of some frame (even
from another session, that might even be iconified now) were saved, and then
the next frame created was offset from that.

Previously, Emacs gave consistent and reasonable results for `make-frame' -
both Emacs 20 and previous Emacs 22 builds. Now, it seems that one doesn't
know what to expect. However, it's not random - something seems to be going
on in some way related to frames previously created (even in previous
sessions).

----

Now, I see that you (Eli) say that this new, inconsistent and unpredictable
behavior is a feature:

    With "emacs -Q", this is the intended behavior:
    the latest changes let the system locate the Emacs
    frame.  The original cause for the change
    was to avoid locating the Emacs frame in the
    portions of the screen occupied by the task bar
    and other decorations.

I understand the motivation, but I, for one, don't like this improvement one
bit. I don't remember seeing this design change discussed, BTW.

First, `default-frame-alist' should be rigorously respected - it seems to be
ignored wrt position now. Second, a user should not *need* to provide
position settings for `default-frame-alist' (or even to provide a
`default-frame-alist') in order to get consistent results when s?he opens
Emacs.

Windows apps generally do not behave in this inconsistent way, trying to
avoid the task bar - most simply open at 0,0. The new behavior seems silly,
and is quite annoying, IMO. If people don't laugh at it, they will curse at
it.

There should be a default value for top, left = 0,0, as before. Anything
else seems weird and unnatural. If the reason for this change was to avoid
the position of the task bar, then I would say:

- The cure is far worse than the disease.

- If there is a good way for Emacs to determine
  the task-bar position, then it could DTRT in
  this regard - *not* just leave positioning up
  to the window manager or the stars.

- If there is no good way for Emacs to determine
  the task-bar position, then it should position
  frames as before, and let the user, who can
  know the task bar position, deal with
  positioning frames to avoid it.

Here is the version I was testing:

In GNU Emacs 22.0.50.1 (i386-msvc-nt5.1.2600)
 of 2006-07-19 on BOS-CTHEWLAP2
X server distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-msvc (12.00)'