From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: Emacs geometry Date: Tue, 25 Jul 2006 11:56:59 -0700 Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1153853964 1607 80.91.229.2 (25 Jul 2006 18:59:24 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 25 Jul 2006 18:59:24 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jul 25 20:59:22 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1G5S7h-0004q8-QP for ged-emacs-devel@m.gmane.org; Tue, 25 Jul 2006 20:59:18 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G5S7h-0001qa-Db for ged-emacs-devel@m.gmane.org; Tue, 25 Jul 2006 14:59:17 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1G5S7V-0001qN-1A for emacs-devel@gnu.org; Tue, 25 Jul 2006 14:59:05 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1G5S7T-0001pz-RW for emacs-devel@gnu.org; Tue, 25 Jul 2006 14:59:04 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G5S7T-0001pu-Ld for emacs-devel@gnu.org; Tue, 25 Jul 2006 14:59:03 -0400 Original-Received: from [148.87.113.118] (helo=rgminet01.oracle.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.52) id 1G5S8q-000505-FM for emacs-devel@gnu.org; Tue, 25 Jul 2006 15:00:28 -0400 Original-Received: from rcsmt251.oracle.com (rcsmt251.oracle.com [148.87.90.196]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id k6P3N7Ep017163 for ; Tue, 25 Jul 2006 12:59:01 -0600 Original-Received: from dhcp-amer-csvpn-gw2-141-144-72-158.vpn.oracle.com by rcsmt251.oracle.com with ESMTP id 1638280571153853822; Tue, 25 Jul 2006 12:57:02 -0600 Original-To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Whitelist: TRUE X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:57632 Archived-At: 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...