From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: moving window handling into lisp Date: Sun, 16 Aug 2009 12:26:29 +0200 Message-ID: <4A87DED5.6010709@gmx.at> References: <4A83E2ED.2090805@gmx.at> <4A868A1F.4020101@gmx.at> <4A86AD92.7030308@gmx.at> <87vdkpfbeg.fsf@lola.goethe.zz> <4A86DE30.8060902@gmx.at> <4A86F24D.4090103@gmx.at> <878whknbj5.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1250418867 28226 80.91.229.12 (16 Aug 2009 10:34:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 16 Aug 2009 10:34:27 +0000 (UTC) Cc: Lennart Borgman , emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Aug 16 12:34:20 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 1Mcd47-0000DR-9b for ged-emacs-devel@m.gmane.org; Sun, 16 Aug 2009 12:34:19 +0200 Original-Received: from localhost ([127.0.0.1]:54342 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mcd46-0007dO-Oc for ged-emacs-devel@m.gmane.org; Sun, 16 Aug 2009 06:34:18 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mccwi-0002bY-H0 for emacs-devel@gnu.org; Sun, 16 Aug 2009 06:26:41 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mccwd-0002aF-KQ for emacs-devel@gnu.org; Sun, 16 Aug 2009 06:26:40 -0400 Original-Received: from [199.232.76.173] (port=53149 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mccwc-0002Zm-9e for emacs-devel@gnu.org; Sun, 16 Aug 2009 06:26:34 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]:50636) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1Mccwb-00077l-MP for emacs-devel@gnu.org; Sun, 16 Aug 2009 06:26:34 -0400 Original-Received: (qmail invoked by alias); 16 Aug 2009 10:26:31 -0000 Original-Received: from 62-47-43-46.adsl.highway.telekom.at (EHLO [62.47.43.46]) [62.47.43.46] by mail.gmx.net (mp067) with SMTP; 16 Aug 2009 12:26:31 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+1x54w4pm1b+8txOOxv5NUUTJoZCNAFVHbkqo8BL 1PULzUZHUVdAji User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: <878whknbj5.fsf@uwakimon.sk.tsukuba.ac.jp> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.63 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:114296 Archived-At: > > Suppose the Emacs frame is a window in a tiling WM that just asked > > Emacs to shrink that frame because the user needs it for another > > application. > > [...] > > Believe me. Deleting windows in some way is the one bullet we do have > > to bite here. > > But you're wrong! A (radical) alternative is to shrink the Emacs > windows as much as possible, then ignore further shrinkage.[1] Ignoring `window-min-height' and `window-min-width' when shrinking frames seems to do most of that job already. > The WM will shrink the shell widget's window, and the GUI server will > then clip the Emacs frame to fit. This would usually clip off the echo area, I presume. > user can get any work done anyway, and in that case the user will have > to tell the WM to resize Emacs to a usable size to get work done. Why > not just leave Emacs's internal configuration as it is? When I resize an Emacs frame because I temporarily want to work with another application I usually don't care about the state of Emacs' windows. Leaving the frame configuration in some not very orderly state doesn't strike me as very clean. So such behavior seems acceptable iff I resize one Emacs frame because I want to continue working with another Emacs frame. > That should work nicely on X11. Whether this works on Windows or Aqua > I dunno. I don't have the slightest idea. Interaction with the WM is Jan's department. > Another possibility would be to withdraw (iconify) the Emacs frame if > it's ask to shrink to the point where its windows' minimum size > constraints are violated. The bug reports will be great: "I was > shrinking Emacs and suddenly it collapsed into a nano-black hole, > started spraying X-rays, and cured my cancer!" > > Footnotes: > [1] It might be a good idea to keep Emacs's "viewport" centered on > point in the selected Emacs window. Then again, it might not. We could just show the selected window of that frame and save the old configuration somewhere. The problem of undeleting windows raises its ugly head again :-( martin