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: decode_any_window Date: Sun, 07 Dec 2008 14:02:32 +0100 Message-ID: <493BC968.3050707@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 1228655216 25248 80.91.229.12 (7 Dec 2008 13:06:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 7 Dec 2008 13:06:56 +0000 (UTC) To: emacs-devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Dec 07 14:08:01 2008 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 1L9JMc-000369-Ut for ged-emacs-devel@m.gmane.org; Sun, 07 Dec 2008 14:08:01 +0100 Original-Received: from localhost ([127.0.0.1]:44629 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L9JLM-0001EU-QH for ged-emacs-devel@m.gmane.org; Sun, 07 Dec 2008 08:06:40 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L9JLI-0001EG-1L for emacs-devel@gnu.org; Sun, 07 Dec 2008 08:06:36 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L9JLG-0001D7-Ms for emacs-devel@gnu.org; Sun, 07 Dec 2008 08:06:35 -0500 Original-Received: from [199.232.76.173] (port=43148 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L9JLG-0001D3-D4 for emacs-devel@gnu.org; Sun, 07 Dec 2008 08:06:34 -0500 Original-Received: from mail.gmx.net ([213.165.64.20]:48077) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1L9JLE-0004U4-8l for emacs-devel@gnu.org; Sun, 07 Dec 2008 08:06:34 -0500 Original-Received: (qmail invoked by alias); 07 Dec 2008 13:06:23 -0000 Original-Received: from 62-47-51-238.adsl.highway.telekom.at (EHLO [62.47.51.238]) [62.47.51.238] by mail.gmx.net (mp033) with SMTP; 07 Dec 2008 14:06:23 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19vTzRjujVvn3a/BrBb7ynJxV/4qQvxQ+mX9Zr8Fl tzTniC+pQ1QwRc User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) X-Y-GMX-Trusted: 0 X-FuHaFi: 0.57 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:106646 Archived-At: With Emacs 23 `fit-window-to-buffer' contains the following code: (defun fit-window-to-buffer (&optional window max-height min-height) ... (unless (zerop delta) (enlarge-window delta)) ... (= desired-height (window-height window)) When delta is negative, `enlarge-window' will shrink WINDOW and, if this makes its height less than that of `window-min-height', delete it. OTOH `window-height' operates on ANY window regardless of whether it's live or has been deleted. Now if WINDOW is a full-height child of a parent window which is not the root window of that frame, deleting that parent window calls the routine delete_all_subwindows which, as a special hack, temporarily stores the name of the buffer displayed by WINDOW in the number of lines of the window. As a consequence, (window-height window) returns the buffer previously shown in WINDOW and the test for equality fails because a buffer is neither a number nor a marker. Emacs 22 worked around this problem by temporarily binding `window-min-height' to 1, so WINDOW didn't get deleted. Hence in this special case an apparently reasonable operation fails gracefully for a reason hardly anyone will understand. I'm not sure whether other operations fail equally gracefully. The Elisp manual warns: *Warning:* Erroneous information or fatal errors may result from using a deleted window as if it were live. But this advice is problematic because quite often we can't say what "using" stands for. Do we "use" a deleted window when we call `window-height' on it? The problem is that decode_window considers a window "live" when it has a buffer. Parent windows don't have a buffer but we want to execute `window-height' on them, so we use decode_any_window. I suppose TRT for decode_any_window is to check whether it has either a buffer or a vertical or horizontal child. But maybe we want to decode effectively "dead" windows too for some reason? martin