RE: Emacs geometry

[Drew Adams]

    We could add code to record the last position in the registry, but I'd
    postpone that to after the release.

Why wouldn't that bug be fixed before the release? It is a result of an
incomplete bug fix (or incomplete feature addition).

The current behavior (random?) is worse than what existed before - it
*requires all* users to play with default-frame-alist or (worse!) to fiddle
with the registry, just to have some control over frame positioning.

If the aim was to move to the way other Windows apps behave, and so avoid
overlapping the task bar, then why not go all the way and do what the other
apps do: remember the last-session position, and restore it?

    > Otherwise, if the default behavior is like IE's, that would
    > be good, IMO: 0,0, if no previous session, else same as last
    > position (last session); cascading right and alternately
    > up and down.

    No, 0,0 is a bad choice for those who have the task bar there, we
    should not go back to it.

So what should the *default* position be, then, if there is no last-session
position to recover? Random? That seems broken, to me.

If I had to guess, I'd guess that 90% of Windows users leave the task bar in
its default position, at the bottom of the screen. Of the remaining 10%, how
many do you think put it at the top or the left of the screen? 1/3 = 3%?
Those few users can specify the position they want, instead of depending on
the default position - it is enough to position the frame once, and then
start a new session (provided that bug is fixed).

IOW, have a reasonable default position (= 0,0), and use that if the user
has specified no preference (either by default-frame-alist, or registry, or
last session's position). Minimize the number of users who will need to
override the default - bothering 3% is better than bothering 100%.

Finally, you didn't speak to my suggestion for cascading, instead of down,
down, down...