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: Fri, 14 Aug 2009 09:17:34 +0200 Message-ID: <4A850F8E.7060200@gmx.at> References: <4A6DAD94.8040006@gmx.at> <4A6DAF71.6070002@gmx.at> <4A6DBB3A.90001@gmx.at> <4A6DC1A1.2000208@gmx.at> <4A6DDB61.8090403@gmx.at> <4A6EAB02.6080701@gmx.at> <4A7010D7.3050305@gmx.at> <4A81374E.9050401@gmx.at> <4A8283D8.6070208@gmx.at> <4A83E2ED.2090805@gmx.at> <4A845 6E2.9020400@gmx.at> <87bpmj88uu.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 1250238043 11033 80.91.229.12 (14 Aug 2009 08:20:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 14 Aug 2009 08:20:43 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 14 10:20:36 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 1Mbs1a-0000k7-QT for ged-emacs-devel@m.gmane.org; Fri, 14 Aug 2009 10:20:35 +0200 Original-Received: from localhost ([127.0.0.1]:42219 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mbs1a-0007xY-6T for ged-emacs-devel@m.gmane.org; Fri, 14 Aug 2009 04:20:34 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mbryp-0007Ba-5R for emacs-devel@gnu.org; Fri, 14 Aug 2009 04:17:43 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mbryk-0007Au-77 for emacs-devel@gnu.org; Fri, 14 Aug 2009 04:17:42 -0400 Original-Received: from [199.232.76.173] (port=59004 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mbryk-0007Ar-3T for emacs-devel@gnu.org; Fri, 14 Aug 2009 04:17:38 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]:60859) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1Mbryj-0000kw-I9 for emacs-devel@gnu.org; Fri, 14 Aug 2009 04:17:37 -0400 Original-Received: (qmail invoked by alias); 14 Aug 2009 07:17:35 -0000 Original-Received: from 62-47-41-235.adsl.highway.telekom.at (EHLO [62.47.41.235]) [62.47.41.235] by mail.gmx.net (mp049) with SMTP; 14 Aug 2009 09:17:35 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19YJ/lP+itYJ6+bTGhVbNoQ2hI9++Tce0QwOHMnVG gLcXQlNeFMWKI5 User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: <87bpmj88uu.fsf@uwakimon.sk.tsukuba.ac.jp> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.74 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) 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:114224 Archived-At: > > It's easy to explain: When dragging a modeline, you probably want to > > shrink/enlarge the bottom-most windows above the modeline and > > enlarge/shrink the topmost windows below the modeline first. > > Abstractly, I agree, but note that some UIs don't do that. For > example, in spreadsheets typically dragging on a column divider > resizes only the column immediately to its left, and pushes or pulls > the columns to the right rigidly. I think that behavior is pretty > plausible for multiwindow configurations in an editor, too, but > perhaps not as common as the "adjust adjoining windows" behavior you > proposed. I don't quite understand what you mean. "resizes only" could stand for resizing _just one_ window which would violate our invariant that all windows must form a frame and the (implicit) assumption that the size of the frame must not change when dragging a vertical divider. Note that I was talking about the present behavior. Richard spent some time on debugging it, IIRC. Basically, it wouldn't be difficult to drag the remaining windows "rigidly". Implicitly, this would be realized by resizing some last sibling in that case. The point is that the behavior must be implemented consistently. martin