From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Lennart Borgman Newsgroups: gmane.emacs.devel Subject: Re: moving window handling into lisp Date: Sat, 22 Aug 2009 15:45:18 +0200 Message-ID: References: <4A8D46C9.1010108@gmx.at> <4A8D66D5.3000600@gmx.at> <4A8D92AC.5010404@gmx.at> <4A8E95A3.5040604@gmx.at> <4A8FCFDC.2030608@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1250948759 12535 80.91.229.12 (22 Aug 2009 13:45:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 22 Aug 2009 13:45:59 +0000 (UTC) Cc: Emacs-Devel devel To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Aug 22 15:45:52 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 1Mequm-0007sN-0P for ged-emacs-devel@m.gmane.org; Sat, 22 Aug 2009 15:45:52 +0200 Original-Received: from localhost ([127.0.0.1]:59482 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mequl-000519-9W for ged-emacs-devel@m.gmane.org; Sat, 22 Aug 2009 09:45:51 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Meque-00050I-Kr for emacs-devel@gnu.org; Sat, 22 Aug 2009 09:45:44 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MequZ-0004y7-G6 for emacs-devel@gnu.org; Sat, 22 Aug 2009 09:45:43 -0400 Original-Received: from [199.232.76.173] (port=49373 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MequZ-0004y3-AY for emacs-devel@gnu.org; Sat, 22 Aug 2009 09:45:39 -0400 Original-Received: from an-out-0708.google.com ([209.85.132.241]:48877) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MequY-000233-Rp for emacs-devel@gnu.org; Sat, 22 Aug 2009 09:45:38 -0400 Original-Received: by an-out-0708.google.com with SMTP id b6so526744ana.21 for ; Sat, 22 Aug 2009 06:45:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=UiVv8vXru0c6xfbPzEFMiprJM8OCmgdMjYOWnslUIDg=; b=pYlnZHH+mfV1ylTh7VWP4emylHTj/lyZpPFUBEWeowg6/BhuERFoUqspfwfiABDO2c r7Ry+x0IgAl22j0PVtIaMummGPPabj/wSQDUHPGpWUZXHGnUza9JLQI83MglUz436aZU 6izRipOEqUVI1iBoTcUSNCH8g/joVKU0aMjXs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=uI4oQu4N7YbUDG07CgZkMsBlJErR5j4phXCqbMlmMxbG6k/7wKybg5JiuHM4VhvzAB BcglfZI2bJ6XwXDCwZxTRT2Rg//4m86YZt/ra0V0WIYoudhw17AyCc83B7m6lfJsFb0f ozNWlZbeUND22oD35/8cK1sJvAY0qyy76Jvno= Original-Received: by 10.101.33.9 with SMTP id l9mr2454025anj.98.1250948738148; Sat, 22 Aug 2009 06:45:38 -0700 (PDT) In-Reply-To: <4A8FCFDC.2030608@gmx.at> X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) 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:114514 Archived-At: On Sat, Aug 22, 2009 at 1:00 PM, martin rudalics wrote: >> So what I need is still a way to apply the new sizes without >> restriction checks during that phase. Am I clear enough when I try to >> explain this? How should I do to avoid the restrictions in this phase? > > What problems do you have doing your calculations using copies of the > original sizes? =C2=A0We can initialize these with the current values and > retrieve via `window-new-height' and `window-new-width'. The problem is maybe my broken English... ;-) There is no problem doing calculations on copies. With "apply" I mean applying the calculated sizes to Emacs windows. >> Yes, I know that this is lacking. I have been wondering about this >> part. It is not clear to me how resizing and deletion/creation of >> windows are tighed together in the current code. I think those parts >> should be broken up. > > It's not entirely trivial to do that. =C2=A0Resizing during window deleti= on > must succeed, at least in a second attempt. =C2=A0So if we want to do thi= s in > Elisp we must be able to resize fixed-size windows and never issue a > failure. Yes. I expect we may have to change/override the rules in such cases. This should be built into the routines doing the calculations. >> Then I assume that window configurations must be used to get my >> suggestion to work. The drawback I see then is that window pointers >> migh gets lost. Are there any way around that? > > Which window pointers get lost? I thought that using window configurations you create new windows instead of the old ones when restoring the configuration into the frame. Is not that how it works? If it is then some elisp code might have pointers to the windows. > Like "you can restore the previous configuration within a suitable > frame-size" by hitting ... =C2=A0Maybe. =C2=A0Let's add it to the set of = possible > solutions. Fine. >>>>> You do undelete all the time. =C2=A0It's completely transparent. >>>> How can it be transparent if windows disappears and reappears? I must >>>> be misunderstanding you somehow... >>> There might be no redisplay in between. >> >> How can you avoid that when the frame gets too small? > > `adjust-window-trailing-edge' can temporarily delete a window and > resurrect it without the user noticing because there's no redisplay in > between. =C2=A0When you program in Elisp you can try to inhibit redisplay= but > I would not recommend that. =C2=A0In any case, I don't understand how thi= s > should relate to frames getting to small. There must be some misunderstanding here. Let us skip it for the moment. >>> In many applications (Thunderbird is one of them) I can make subwindows >>> disappear completely by dragging one of their borders and make them >>> reappear later by dragging on the border where they disappeared. >> >> Are there no sign at all that there are 0-size windows there? > > Thunderbird leaves a horizontal divider behind. Thanks. What would be the corresponing divider in Emacs? I mean a mode line for example takes one screen line and would take some space ... - and then perhaps it will not fit...