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, 21 Aug 2009 14:40:49 +0200 Message-ID: <4A8E95D1.7050009@gmx.at> References: <4A87F8B8.6050102@gmx.at> <4A882312.6020106@gmx.at> <4A8D12B3.6070502@gmx.at> <4A8D46C9.1010108@gmx.at> <4A8D66D5.3000600@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1250858653 16360 80.91.229.12 (21 Aug 2009 12:44:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 21 Aug 2009 12:44:13 +0000 (UTC) Cc: Lennart Borgman , emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 21 14:44:06 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 1MeTTR-0003BI-0y for ged-emacs-devel@m.gmane.org; Fri, 21 Aug 2009 14:44:05 +0200 Original-Received: from localhost ([127.0.0.1]:43835 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MeTTQ-0006ar-7k for ged-emacs-devel@m.gmane.org; Fri, 21 Aug 2009 08:44:04 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MeTQS-0005LY-Bl for emacs-devel@gnu.org; Fri, 21 Aug 2009 08:41:00 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MeTQN-0005Iy-Dr for emacs-devel@gnu.org; Fri, 21 Aug 2009 08:41:00 -0400 Original-Received: from [199.232.76.173] (port=46211 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MeTQN-0005In-6C for emacs-devel@gnu.org; Fri, 21 Aug 2009 08:40:55 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]:35286) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1MeTQL-0001Lp-Uv for emacs-devel@gnu.org; Fri, 21 Aug 2009 08:40:54 -0400 Original-Received: (qmail invoked by alias); 21 Aug 2009 12:40:52 -0000 Original-Received: from 62-47-38-0.adsl.highway.telekom.at (EHLO [62.47.38.0]) [62.47.38.0] by mail.gmx.net (mp059) with SMTP; 21 Aug 2009 14:40:52 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19fhEplw8ZfPOe93Y41JRHqYyPTJCd1KbHW8hbvJ4 kYtc6NuK5T2YYw User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: X-Y-GMX-Trusted: 0 X-FuHaFi: 0.64 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:114474 Archived-At: > One of the benefits of moving window resizing into Lisp > is that people will be able to easiy try out various different > ways of doing it. So we need not try to decide the best way > by a discussion about abstractions now. > > It will be possible to have different resizing strategies for > different situations, too. Responding to a window manager need not be > the same as responding to the user's dragging a boundary. Currently, resizing a window W vertically is implemented by the following routines: - `enlarge_window' resizes W by stealing/giving space from/to windows above and/or below W and may delete windows when they get too small. `enlarge_window' does it's job by always calling `set_window_height' (see below) with the NODELETE argument 0 so it essentially always gets it's job done. Note that `enlarge_window' is the routine implementing the commands `enlarge-window' and `shrink-window' so the majority of Emacs' window resizing operations is done here. - `set_window_height' deletes windows when called by `enlarge_window' and display initialization (but this should hardly matter) and currently tries to not delete windows when called by the frame resizing routines (unless there's no other way because the windows won't fit). Generally, `set-window_height' only serves as an interface to `size_window' (see below). - `size_window' is the basic resizing routine. It currently can either delete other windows unconditionally, delete other windows only when they shrink below `window-min-height', or delete them when they shrink to zero. It apparently doesn't handle fixed-size windows correctly and does a poor job re-resizing windows. - `adjust_window_trailing_edge' resizes W by stealing/giving space from/to the window below W and does not delete windows when they get too small. `adjust_window_trailing_edge' is used when dragging a modeline or vertical divider and calls size_window with the NODELETE argument 0. Due to its ability to not delete any windows it's also called by `balance-windows-area'. To avoid that a window gets deleted it saves and restores window-configuration but this could be likely resolved by having it call size_window with NODELETE non-zero. Due to the bug in `size_window', `adjust_window_trailing_edge' doesn't handle fixed-size windows correctly. - `delete_window' resizes either the sibling above or below W and is not allowed to delete other windows. So inherently `delete_window' is not able to handle fixed-size windows correctly even if size_window were. - `split-window' resizes only W (where W is the window that shall be split) and does not delete any other window. Currently, `split-window' is trivial because it operates on leaf windows only. As a consequence, you can, for example, never create a full-width window in a frame with two side-by-side windows without deleting one of these windows first which I consider a considerable drawback. If `split-window' were allowed to split internal windows, some more intelligent resizing routine would be needed. - `resize_mini_window' shrinks windows above W (where W is the minibuffer window) using a routine called `shrink_window_lowest_first' which does not delete windows. `resize_mini_window' can also enlarge other windows by calling `enlarge_window' which should not delete any window (but I'm not 100% sure about that). Also `resize_mini_window' saves the original sizes of windows shrunk/enlarged in the `orig_total_lines' and `orig_top_line' slots and uses these to restore the original values when it's job is done (something like a built-in version of saving and restoring the window configuration) With the exception of `resize_mini_window' similar behaviors apply for resizing W horizontally. Even if we don't implement resizing in Elisp the following issues have not been discussed yet: - Whether resizing may delete other windows depends on the interface to size_window chosen. We can easily make `enlarge-window' not delete other windows by giving it an optional `no-delete' argument. It's not clear though whether `size_window' does handle the NODELETE argument always correctly. - Many parts of Emacs might rely on the ability of `enlarge-window' to delete other windows. (It's hard to say which because there are too many.) So some intelligent way of deleting other windows might be needed anyway if we wanted `enlarge-window' to not delete any windows. - Ideally, we would have one function doing the job of `size_window' and that function could be used by `resize_mini_window' as well. That function would probably take all the arguments `size_window' currently does. And that function would have to handle fixed-size windows correctly and re-resize windows using David's fractional heights and widths. martin