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: Working with one buffer in two frames/windows Date: Sat, 12 Jul 2008 14:22:19 +0200 Message-ID: <4878A1FB.9060000@gmx.at> References: <86tzew3d1c.fsf@lola.quinscape.zz> <85myknqzq2.fsf@lola.goethe.zz> <48788A04.8020204@gmx.at> <85lk07pdpx.fsf@lola.goethe.zz> 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 1215866593 17864 80.91.229.12 (12 Jul 2008 12:43:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 12 Jul 2008 12:43:13 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jul 12 14:44:00 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 1KHeSG-0000BU-BM for ged-emacs-devel@m.gmane.org; Sat, 12 Jul 2008 14:44:00 +0200 Original-Received: from localhost ([127.0.0.1]:44612 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KHeRN-0008FR-Mx for ged-emacs-devel@m.gmane.org; Sat, 12 Jul 2008 08:43:05 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KHeRD-0008DV-Uu for emacs-devel@gnu.org; Sat, 12 Jul 2008 08:42:56 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KHeR9-0008B3-4E for emacs-devel@gnu.org; Sat, 12 Jul 2008 08:42:52 -0400 Original-Received: from [199.232.76.173] (port=53121 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KHeR9-0008Az-16 for emacs-devel@gnu.org; Sat, 12 Jul 2008 08:42:51 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]:37748) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1KHe7X-0002Qz-QX for emacs-devel@gnu.org; Sat, 12 Jul 2008 08:22:36 -0400 Original-Received: (qmail invoked by alias); 12 Jul 2008 12:22:34 -0000 Original-Received: from 62-47-61-121.adsl.highway.telekom.at (EHLO [62.47.61.121]) [62.47.61.121] by mail.gmx.net (mp026) with SMTP; 12 Jul 2008 14:22:34 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18wkoQn8RAwmjJxUN6BgukhiOl073sbs9mRXszRFt rUT5VPBX3301zn User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: de-DE, de, en-us, en In-Reply-To: <85lk07pdpx.fsf@lola.goethe.zz> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.6899999999999999 X-detected-kernel: 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:100612 Archived-At: >>If you have problems with `View-quit' when viewing a help buffer please >>report here. I have tried to handle that case but might have failed. > > I just tried for 10-seconds and it might do the right thing. It should work correctly as long as the help buffer is shown in one window only. It might fail when you show the help buffer in multiple windows because `view-return-to-alist' is buffer-local. > However, > killing the view buffer with C-x k RET does not. And other things that > likely use the equivalent of bury-buffer don't either. Doing any C-x 4 > like stuff will lose you the point information in the other window, > permanently. M-x gnus RET in particular will leave a mess after > finishing concerning both window configuration and buffer selection (at > least if you view at least one article and thus get into split view). > > One major drawback of many window systems is productivity loss because > you have to move around and rearrange windows in order to get a certain > job done. And the Emacs windows assignment methods cause similar user > threshing where you have to invest time to regain a working > configuration. We could set up a window-local equivalent of `view-return-to-alist' and every time one quits or otherwise replaces the buffer, the previous, explicitly placed there, buffer would get restored together with its window-point and maybe other window-related/buffer-local information. Alternatively, we could save the current window configuration when invoking help or gnus and restore that configuration when quitting. Personally I find this behavior annoying because it also destroys all other changes in the window configuration I have done in the meantime. A typical case is the backtrace buffer where I sometimes wind up investigating the cause of an error in other windows. When I eventually decide to quit backtrace, all those new windows get killed too, leaving me with a configuration I neither want nor need at that time.