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: help-window-select and info-lookup-symbol Date: Tue, 21 Jul 2009 15:27:26 +0200 Message-ID: <4A65C23E.3010801@gmx.at> References: <4A6439A9.6080406@gmx.at> 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 1248182885 28160 80.91.229.12 (21 Jul 2009 13:28:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 21 Jul 2009 13:28:05 +0000 (UTC) Cc: emacs-devel@gnu.org To: Helmut Eller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jul 21 15:27:58 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 1MTFNd-0006us-9f for ged-emacs-devel@m.gmane.org; Tue, 21 Jul 2009 15:27:41 +0200 Original-Received: from localhost ([127.0.0.1]:59887 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MTFNc-0006QQ-ML for ged-emacs-devel@m.gmane.org; Tue, 21 Jul 2009 09:27:40 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MTFNX-0006PH-MB for emacs-devel@gnu.org; Tue, 21 Jul 2009 09:27:35 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MTFNS-0006LN-HV for emacs-devel@gnu.org; Tue, 21 Jul 2009 09:27:34 -0400 Original-Received: from [199.232.76.173] (port=54829 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MTFNS-0006L7-Be for emacs-devel@gnu.org; Tue, 21 Jul 2009 09:27:30 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]:60960) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1MTFNR-0007Ww-JA for emacs-devel@gnu.org; Tue, 21 Jul 2009 09:27:30 -0400 Original-Received: (qmail invoked by alias); 21 Jul 2009 13:27:27 -0000 Original-Received: from 62-47-56-251.adsl.highway.telekom.at (EHLO [62.47.56.251]) [62.47.56.251] by mail.gmx.net (mp049) with SMTP; 21 Jul 2009 15:27:27 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19fQNEjasJfVJ/Xm/vyBjg9BmAtPKFj3I9DLW6ktB 7ey31HuJttUoat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: X-Y-GMX-Trusted: 0 X-FuHaFi: 0.67 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:112901 Archived-At: >> A brute force >> approach (currently used by info or backtrace) simply restores W1 whe >> you press `q' which all so often drives me mad because it destroys the >> windows and window-buffer associations I have created in between. > > For the debugger it's IMO the best option. When debugging an application which creates a new buffer I have to create that buffer before running the application in order to see how it gets filled. Otherwise, the debugger won't let me see it for long. Maybe I could show it in another frame, but I don't want to resize my main frame in order to make another one visible. >> Now theoretically, I could restore W1 if and only if the configurations >> W2 and W3 are equal. In practice, however, this approach often failed >> here. Hence, I tried to base the comparison on a weaker predicate of >> equality which ignored the identities of buffers displayed in other >> windows and the relative sizes of windows. I got it to work for help >> buffers but was not able to make it work realiably with info buffers. > > Comparing W2 and W3 per compare-window-configurations would probably > work as a start, but point should probably not be restored. My info windows are sometimes open for a couple of minutes, mostly because I'm to lazy to quit them. Quitting them at last offers me an interesting albeit chaotic view of my session's archeology. > (defun slime-close-popup-window () > (when slime-popup-restore-data > (destructuring-bind (popup-window selected-window old-buffer) > slime-popup-restore-data > (bury-buffer) > (when (eq popup-window (selected-window)) > (cond ((and (not old-buffer) (not (one-window-p))) > (delete-window popup-window)) > ((and old-buffer (buffer-live-p old-buffer)) > (set-window-buffer popup-window old-buffer)))) > (when (window-live-p selected-window) > (select-window selected-window))) > (kill-local-variable 'slime-popup-restore-data))) > > popup-window is the window that displays the help content at W2. > selected-window was selected at W1. > old-buffer was the buffer associated with popup-window at W1. How do you get the `old-buffer' and `popup-window' values in general? By comparing window configurations before and after `display-buffer'? My code included for every window a variable telling whether that window was split off by `display-buffer' or which buffer the window displayed before it was "used" by `display-buffer'. I recall it proved very nasty to save the old buffer value when the window is re-used again by `display-buffer' because I had to avoid that a "valuable" non-help content buffer value would get overwritten by the "uselss" value of a help-content buffer. martin