From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: grischka Newsgroups: gmane.emacs.devel Subject: Re: moving window handling into lisp Date: Mon, 17 Aug 2009 21:06:46 +0200 Message-ID: <4A89AA46.6050502@gmx.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1250536034 31817 80.91.229.12 (17 Aug 2009 19:07:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 17 Aug 2009 19:07:14 +0000 (UTC) Cc: emacs-devel@gnu.org To: rudalics@gmx.at Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 17 21:07:06 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1Md7Xs-0003iV-Ia for ged-emacs-devel@m.gmane.org; Mon, 17 Aug 2009 21:07:04 +0200 Original-Received: from localhost ([127.0.0.1]:34449 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Md7Xr-0006k2-Qr for ged-emacs-devel@m.gmane.org; Mon, 17 Aug 2009 15:07:03 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Md7Xm-0006iE-Pp for emacs-devel@gnu.org; Mon, 17 Aug 2009 15:06:58 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Md7Xi-0006c9-39 for emacs-devel@gnu.org; Mon, 17 Aug 2009 15:06:58 -0400 Original-Received: from [199.232.76.173] (port=60454 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Md7Xh-0006bv-WF for emacs-devel@gnu.org; Mon, 17 Aug 2009 15:06:54 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]:53280) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1Md7Xg-0003V7-T0 for emacs-devel@gnu.org; Mon, 17 Aug 2009 15:06:53 -0400 Original-Received: (qmail invoked by alias); 17 Aug 2009 19:06:49 -0000 Original-Received: from p57A097B0.dip0.t-ipconnect.de (EHLO [192.168.1.4]) [87.160.151.176] by mail.gmx.net (mp062) with SMTP; 17 Aug 2009 21:06:49 +0200 X-Authenticated: #18588216 X-Provags-ID: V01U2FsdGVkX18M0Vs/fCkMGa7Fzfe3TwQp2a/tuU3Kd3QB7m9c/X jl0f0RL7jQaTuO User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) Original-References: 4A885D0A.3060805@gmx.at X-Y-GMX-Trusted: 0 X-FuHaFi: 0.6899999999999999 X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. 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:114350 Archived-At: From: martin rudalics > > In a nutshell: whatever position is manipulated _directly_ is made an > > integer at the time of the manipulation. Window borders that are only > > repositioned as an implicit (proportionate) result of some resizing > > operation, do the bookkeeping of their position as a fraction that > > corresponds to the resized ratios. > > > Very neat idea, indeed. As a matter of fact this should solve the frame > re-resizing problem completely. To solve a problem it not only needs the right algorithm but also the right implementation. Take for example proportional resizing as it is currently. If I make a frame with two windows side by side, 20 and 70 chars wide and if I maximize the frame, the window widths are now 63 and 113, and if I un-maximize it again the widths are now 31 and 59. That clearly is not a problem that can be solved by ideas, as neat as they may be. It is plain simple broken math. --- grischka