From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: moving window handling into lisp Date: Sun, 16 Aug 2009 18:15:46 +0200 Organization: Organization?!? Message-ID: <87vdknd9al.fsf@lola.goethe.zz> References: <4A86AD92.7030308@gmx.at> <87vdkpfbeg.fsf@lola.goethe.zz> <4A86DE30.8060902@gmx.at> <4A86F24D.4090103@gmx.at> <4A87DE88.6050209@gmx.at> <87bpmgdkjb.fsf@lola.goethe.zz> <4A8822F1.8040506@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1250439496 31001 80.91.229.12 (16 Aug 2009 16:18:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 16 Aug 2009 16:18:16 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Aug 16 18:18:09 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 1MciQq-0003UI-GU for ged-emacs-devel@m.gmane.org; Sun, 16 Aug 2009 18:18:08 +0200 Original-Received: from localhost ([127.0.0.1]:55253 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MciQp-0005GR-QM for ged-emacs-devel@m.gmane.org; Sun, 16 Aug 2009 12:18:07 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MciQk-0005GI-H5 for emacs-devel@gnu.org; Sun, 16 Aug 2009 12:18:02 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MciQg-0005Fy-4W for emacs-devel@gnu.org; Sun, 16 Aug 2009 12:18:02 -0400 Original-Received: from [199.232.76.173] (port=43409 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MciQf-0005Fv-V5 for emacs-devel@gnu.org; Sun, 16 Aug 2009 12:17:57 -0400 Original-Received: from main.gmane.org ([80.91.229.2]:45525 helo=ciao.gmane.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MciQf-0002Gu-I2 for emacs-devel@gnu.org; Sun, 16 Aug 2009 12:17:57 -0400 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1MciQX-00041f-Ra for emacs-devel@gnu.org; Sun, 16 Aug 2009 16:17:49 +0000 Original-Received: from p5b2c31bb.dip.t-dialin.net ([91.44.49.187]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 16 Aug 2009 16:17:49 +0000 Original-Received: from dak by p5b2c31bb.dip.t-dialin.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 16 Aug 2009 16:17:49 +0000 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 38 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: p5b2c31bb.dip.t-dialin.net X-Face: 2FEFf>]>q>2iw=B6, xrUubRI>pR&Ml9=ao@P@i)L:\urd*t9M~y1^:+Y]'C0~{mAl`oQuAl \!3KEIp?*w`|bL5qr,H)LFO6Q=qx~iH4DN; i"; /yuIsqbLLCh/!U#X[S~(5eZ41to5f%E@'ELIi$t^ Vc\LWP@J5p^rst0+('>Er0=^1{]M9!p?&:\z]|;&=NP3AhB!B_bi^]Pfkw User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) Cancel-Lock: sha1:P6uuR323o+3tLzGt9Fl3lQkweO8= X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) 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:114319 Archived-At: martin rudalics writes: >> What _is_ the "old structure" when resizing opaquely? It might be >> easiest to store window sizes as fractions. When resizing a frame, the >> fractions don't change (so the internal window configuration snaps to >> the closest integral value). When resizing individual windows, the >> fractions are made whole again, matching the character positions of the >> frame. > > I'm not sure how to understand the last sentence. Why and how are > "fractions made whole again"? A fraction for a window border position remains a fraction (of the frame size) if it is an inherent result of resizing the frame. If the user adjusts individual window borders, however, their new position is an integer since it is not an implicit result of frame resizing. 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. >> Note that storing stuff in that manner also allows repeated toggles of >> tool-bar-mode and similar to revert to the original frame configuration >> painlessly since the outer window edges (which can't be repositioned >> within a frame) retain the original fractions indefinitely as long as >> the frame itself is not resized manually. > > I suppose the outer window edges also change fractions when the window > is resized manually. Or what am I missing? Resizing manually manipulates the outer window edges directly. So they are candidates for integral representations as a result of the manipulation. -- David Kastrup