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: Mon, 20 Jul 2009 11:32:25 +0200 Message-ID: <4A6439A9.6080406@gmx.at> References: 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 1248082430 1817 80.91.229.12 (20 Jul 2009 09:33:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 20 Jul 2009 09:33:50 +0000 (UTC) Cc: emacs-devel@gnu.org To: Helmut Eller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 20 11:33:43 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 1MSpFe-0004LG-F4 for ged-emacs-devel@m.gmane.org; Mon, 20 Jul 2009 11:33:42 +0200 Original-Received: from localhost ([127.0.0.1]:40248 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MSpFd-0007FT-MO for ged-emacs-devel@m.gmane.org; Mon, 20 Jul 2009 05:33:41 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MSpEX-0006Pn-6W for emacs-devel@gnu.org; Mon, 20 Jul 2009 05:32:33 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MSpES-0006Ly-ND for emacs-devel@gnu.org; Mon, 20 Jul 2009 05:32:32 -0400 Original-Received: from [199.232.76.173] (port=54584 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MSpES-0006Ls-7Q for emacs-devel@gnu.org; Mon, 20 Jul 2009 05:32:28 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]:40390) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1MSpER-0000Nd-KP for emacs-devel@gnu.org; Mon, 20 Jul 2009 05:32:28 -0400 Original-Received: (qmail invoked by alias); 20 Jul 2009 09:32:26 -0000 Original-Received: from 62-47-60-225.adsl.highway.telekom.at (EHLO [62.47.60.225]) [62.47.60.225] by mail.gmx.net (mp048) with SMTP; 20 Jul 2009 11:32:26 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1878qwbEcU7Auyltsv0nPTQmNIpZMeETZWAlMusj9 jbGw5z3UpvCOlv User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: X-Y-GMX-Trusted: 0 X-FuHaFi: 0.63 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:112817 Archived-At: > It seems to me that C-h S and C-h f are so similar that both commands > should honor the value of help-window-select. In fact, there are a lot > of (third party) packages with a display-documentation-in-other-window > command but there seems to be no agreement whether the window should be > selected or not. Especially annoying is the fact that XEmacs usually > selects the other window while Emacs usually does not. C-h f is a self-contained function while C-h S falls back on `info' for displaying its findings. Obviously, a common approach to handle these and similar cases would be desirable. > It would be very nice if you, the Emacs maintainers, could make a rule > or style-guide how this should be done. E.g. should other packages look > at help-window-select or is that an "internal" variable of help-mode? Currently `help-window-select' is an "internal" variable of help-mode. > I understand that restoring the window configuration after pressing q in > the help window (or info window, or w3m buffer) is sort of tricky and it > gets very complex if multiple frames are involved, yet selecting the > help window is what many users expect. Since restoring is so tricky it > would also be helpful if there were some general functions to do it > properly. Restoring an old window configuration is awfully tricky. Let W1 denote the window configuration before invoking help, W2 the configuration after invoking help (and after any `fit-window-to-buffer' and balancing stuff), and W3 the configuration when you press `q'. 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. 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. martin