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: Window configurations Date: Tue, 11 May 2010 09:01:59 +0200 Message-ID: <4BE900E7.3090402@gmx.at> References: <4BB4CF6B.2000007@alice.it> <87vdbhgqgd.fsf@mail.jurta.org> <828BB36311A84C43B96D1F2A559DACAE@us.oracle.com> <87d3xo662u.fsf@mail.jurta.org> <69D40D69CC6F4982A8E91D8D8F0F494F@us.oracle.com> <87r5m4hz39.fsf@mail.jurta.org> <4BD40821.70808@gmx.at> <87zl0rtmqy.fsf@mail.jurta.org> <871vdu6qn5.fsf@mail.jurta.org> <87bpcv1wvt.fsf@mail.jurta.org> <4BE13828.2030609@gmx.at> <87vdb2qo82.fsf@mail.jurta.org> <4BE27C17.3030005@gmx.at> <87vdav4vx5.fsf@mail.jurta.org> 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: dough.gmane.org 1273561351 5505 80.91.229.12 (11 May 2010 07:02:31 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 11 May 2010 07:02:31 +0000 (UTC) Cc: Ken Hori , Emacs To: Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue May 11 09:02:30 2010 connect(): No such file or directory 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.69) (envelope-from ) id 1OBjU5-0007Et-S7 for ged-emacs-devel@m.gmane.org; Tue, 11 May 2010 09:02:30 +0200 Original-Received: from localhost ([127.0.0.1]:55040 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OBjU5-0003Cf-BI for ged-emacs-devel@m.gmane.org; Tue, 11 May 2010 03:02:29 -0400 Original-Received: from [140.186.70.92] (port=50900 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OBjTt-0003BH-C3 for emacs-devel@gnu.org; Tue, 11 May 2010 03:02:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OBjTk-0007N2-Lf for emacs-devel@gnu.org; Tue, 11 May 2010 03:02:14 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]:52923) by eggs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1OBjTi-0007M1-0P for emacs-devel@gnu.org; Tue, 11 May 2010 03:02:08 -0400 Original-Received: (qmail invoked by alias); 11 May 2010 07:02:01 -0000 Original-Received: from 62-47-33-243.adsl.highway.telekom.at (EHLO [62.47.33.243]) [62.47.33.243] by mail.gmx.net (mp037) with SMTP; 11 May 2010 09:02:01 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18xrSlbnOgxYQ38DuxUZUHDaJs85KWjWC5KH5usgi qDL6TzBtfeqnP6 User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: <87vdav4vx5.fsf@mail.jurta.org> X-Y-GMX-Trusted: 0 X-detected-operating-system: by eggs.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:124693 Archived-At: > Thinking more about this, I believe now this function should be > like `view-mode-exit': I had something like this in mind. BTW, I have rewritten this code in the meantime using a window parameter called `quit-restore'. From a preliminary description ... The `quit-restore' parameter tells how to proceed with a window when the user "quits" it by invoking `quit-restore-window', see *Note Displaying Buffers::. The following non-`nil' values of this parameter have a special meaning. `t' This means to delete the associated window. By default, `t' is used for a "temporary" window that was obtained by splitting an existing window. `frame' This means to delete the associated window's frame. This value indicates that the associated windows was obtained by popping up a new frame showing just this window. If the window is no more needed, it should be deleted together with the containing frame. A list This option is useful when the associated window was borrowed to temporarily display some buffer and quitting shall "restore" the previous contents of the window. The first three elements of the list must specify a buffer, a window start position, and a window point. Quitting the window will then try to display the indicated buffer with the given start position and point in that window. The fourth element, if non-`nil', must denote a live buffer. If specified, quitting will restore the previous window contents if and only if the buffer shown in the window is the buffer named by this element. The fifth element, if non-`nil', should specify the desired height of the window when its buffer is restored. This value is applied if the buffer temporarily shown in the window was in `temp-buffer-resize-mode' to restore the original height of the window. ... and the description of `quit-restore-window' goes like ... The command described next allows to quit the window chosen by `display-buffer' and restore the previous state without undoing changes to the window configuration that happend _after_ `display-buffer' was called. A more drastic solution is to save the window configuration before calling `display-buffer' and eventually restoring the saved configuration, *Note Window Configurations::. That solution sometimes has the undesirable side-effect that all changes that happened after the configuration was saved are undone too. -- Command: quit-restore-window &optional window kill This command "quits" WINDOW restoring its previous contents if possible. The argument WINDOW must be a live window and defaults to the selected one. This function always returns `nil'. According to information stored in WINDOW's `quit-restore' window parameter (*note Window Parameters::) this function performs one of the following actions. * Delete WINDOW and its frame. This action is useful when WINDOW was created on a standalone frame and there are other frames left. * Delete WINDOW. This action is usually taken when WINDOW was obtained by splitting some existing window. * Restore the buffer previously displayed in WINDOW. This action is taken when WINDOW was temporarily reused for displaying some other buffer. * Make WINDOW display some other buffer. This action is usually taken when the three preceding ones are not applicable. If its value was non-`nil', this function resets WINDOW's `quit-restore' parameter to `nil'. If the optional argument KILL is non-`nil', this means in addition kill WINDOW's buffer. If KILL is `nil', this simply puts WINDOW's buffer at the end of the buffer list. Interactively, KILL is the prefix argument. ... where `quit-restore-window' here replaces `quit-window' which has too obscure semantics for my taste. And obviously, exiting `view-mode' calls `quit-restore-window' here too. However, restoring a window configuration is a more primitive operation than exiting `view-mode'. One of the most hairy situation occurs when you kill a buffer: There's a window of vulnerability when the `kill-buffer' routine calls `replace_buffer_in_all_windows' and the latter, for some reason, doesn't do what it has been told, for example, because a `window-configuration-change-hook' shows the buffer to be killed in some other window. Obviously, doing things like that in a configuration change hook is foolish as in (get-buffer-create "*foo*") (defun foo-lish () (let (window-configuration-change-hook) (set-window-buffer (frame-first-window) "*foo*"))) (add-hook 'window-configuration-change-hook 'foo-lish) and now doing (kill-buffer "*foo*"). But I'm not sure whether there are useful things a `window-configuration-change-hook' could do along these lines. martin