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 14:12:56 +0200 Organization: Organization?!? Message-ID: <87bpmgdkjb.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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1250424906 9920 80.91.229.12 (16 Aug 2009 12:15:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 16 Aug 2009 12:15:06 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Aug 16 14:14:59 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 1McedX-0007T2-5V for ged-emacs-devel@m.gmane.org; Sun, 16 Aug 2009 14:14:59 +0200 Original-Received: from localhost ([127.0.0.1]:59288 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1McedW-0008L4-BU for ged-emacs-devel@m.gmane.org; Sun, 16 Aug 2009 08:14:58 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mcebv-0007ru-FY for emacs-devel@gnu.org; Sun, 16 Aug 2009 08:13:19 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mcebo-0007os-Fy for emacs-devel@gnu.org; Sun, 16 Aug 2009 08:13:18 -0400 Original-Received: from [199.232.76.173] (port=44659 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mcebo-0007om-AU for emacs-devel@gnu.org; Sun, 16 Aug 2009 08:13:12 -0400 Original-Received: from main.gmane.org ([80.91.229.2]:42637 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 1Mcebn-000777-UV for emacs-devel@gnu.org; Sun, 16 Aug 2009 08:13:12 -0400 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Mcebj-0004Vj-42 for emacs-devel@gnu.org; Sun, 16 Aug 2009 12:13:07 +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 12:13:07 +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 12:13:07 +0000 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 32 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:LFOyLlRwZhB9b/63UoT1e6uENT0= 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:114301 Archived-At: Lennart Borgman writes: > On Sun, Aug 16, 2009 at 12:25 PM, martin rudalics wrote: >>> However in that case I would still suggest showing one window >>> temporary and explain and give alternatives there. I can't see that it >>> is worse than just deleting the windows. Just deleting the windows >>> might look like a bug - or maybe just not be noticed, be confusing. >> >> It hardly was a problem recently.  What's more important IMHO is that >> when we shrink a frame and re-enlarge it afterwards we should get the >> previous sizes.  That's, however, more difficult to do. > > > What is problematic with that if we save pointers to the old structure > as I suggested? (I am not saying there aren't any problem, I just > don't know what kind of problem you see.) 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. 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. -- David Kastrup