From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#8358: 24.0.50; `minibuffer-scroll-window' with active minibuffer: always *Completions*? Date: Mon, 28 Mar 2011 17:01:57 +0200 Message-ID: <4D90A2E5.9020206@gmx.at> References: <85A4B6FC9D55449098D84231439FAF9B@us.oracle.com> <4D902BEF.7050107@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: dough.gmane.org 1301325050 2651 80.91.229.12 (28 Mar 2011 15:10:50 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 28 Mar 2011 15:10:50 +0000 (UTC) Cc: 8358@debbugs.gnu.org To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Mar 28 17:10:46 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1Q4E5X-0007Ds-9a for geb-bug-gnu-emacs@m.gmane.org; Mon, 28 Mar 2011 17:10:42 +0200 Original-Received: from localhost ([127.0.0.1]:34710 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q4E5V-0005TK-67 for geb-bug-gnu-emacs@m.gmane.org; Mon, 28 Mar 2011 11:10:37 -0400 Original-Received: from [140.186.70.92] (port=36802 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q4E2D-00030D-KH for bug-gnu-emacs@gnu.org; Mon, 28 Mar 2011 11:07:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q4E2B-0005DW-CA for bug-gnu-emacs@gnu.org; Mon, 28 Mar 2011 11:07:13 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:49584) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q4E2B-0005DL-9x for bug-gnu-emacs@gnu.org; Mon, 28 Mar 2011 11:07:11 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1Q4DyA-0007ev-6o; Mon, 28 Mar 2011 11:03:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 28 Mar 2011 15:03:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8358 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 8358-submit@debbugs.gnu.org id=B8358.130132452929375 (code B ref 8358); Mon, 28 Mar 2011 15:03:02 +0000 Original-Received: (at 8358) by debbugs.gnu.org; 28 Mar 2011 15:02:09 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Q4DxI-0007dk-EY for submit@debbugs.gnu.org; Mon, 28 Mar 2011 11:02:08 -0400 Original-Received: from mailout-de.gmx.net ([213.165.64.23]) by debbugs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1Q4DxF-0007dG-Hq for 8358@debbugs.gnu.org; Mon, 28 Mar 2011 11:02:07 -0400 Original-Received: (qmail invoked by alias); 28 Mar 2011 15:01:58 -0000 Original-Received: from 62-47-33-185.adsl.highway.telekom.at (EHLO [62.47.33.185]) [62.47.33.185] by mail.gmx.net (mp063) with SMTP; 28 Mar 2011 17:01:58 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1825L5BfTw2QI9AAIsShSzwu6iA9+JYNSvCJ4NYJV Z3nDoIbVUHE61b User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: X-Y-GMX-Trusted: 0 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Mon, 28 Mar 2011 11:03:02 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:45425 Archived-At: >> `with-output-to-temp-buffer' which displays the *Completions* buffer >> sets `minibuffer-scroll-window' to the window showing *Completions*. > > Thanks for the info. But why should that happen? `with-output-to-temp-buffer' > is supposed to be general, for any temporary buffer. It is not supposed to be > specific to *Completions* or *Help* or any other given temporary buffer. > > And the doc of `scroll-other-window' says that "`minibuffer-scroll-window' if > non-nil specifies the window to scroll." It doesn't say that it always > specifies the *Completions* window. > > And the doc of `minibuffer-scroll-window' says "Non-nil means it is the window > that C-M-v in minibuffer should scroll." It doesn't say that C-M-v in the > minibuffer always scrolls *Completions*. > > There is nothing to indicate that things are in fact hard-coded so that the > window to scroll when you are in the minibuffer is always *Completions*. And > there is nothing to indicate that that is the intention (design). > > On the contrary. This is a variable, created presumably to let you change the > window to be scrolled from the minibuffer. And the doc supports this as the > intention. `minibuffer-scroll-window' is not a user option. So by design it's a variable any code is allowed to change. I suppose that it's set in `with-output-to-temp-buffer' because that macro is quite opaque so the caller isn't even informed about which window displays the buffer. >> Try doing >> (add-hook 'temp-buffer-show-hook 'foo 'append) >> instead. Or write your own `temp-buffer-show-function'. > > Thanks, but such a workaround is a sledge hammer here. `temp-buffer-show-hook' > is general, and it should not be necessary to add and remove stuff just to get > `minibuffer-scroll-window' to act as a variable. > > I appreciate the implementation info, but this seems like a bug to me. `temp-buffer-show-hook' is provided to override the built-in behavior of `with-output-to-temp-buffer'. If I were annoyed by the behavior I would use it to fix such problems. > `minibuffer-scroll-window' is used only when the minibuffer is active, and it is > apparently always set, in that case, to the *Completions* window. This was > created as a variable presumably so that programs could change the window to be > scrolled from the minibuffer. Yes. > It's not clear whether you are just explaining what currently happens (thank > you) or you are also saying that this is not a bug. What's the point of > `minibuffer-scroll-window' if it is always effectively *Completions*? I'm only trying to explain what happens, I don't use C-M-v myself. But I suppose that if you removed the corresponding assignment from `with-output-to-temp-buffer', the completions coder would add a similar assignment to `temp-buffer-show-hook'. > Other than this hard-coded case, user code has easy control over > `scroll-other-window(-down)'. Can we please fix this so that > `minibuffer-scroll-window' acts as advertised? The doc-string of `minibuffer-scroll-window' says Non-nil means it is the window that C-M-v in minibuffer should scroll. so IIUC it acts as advertised. If the window has been deleted in the meantime, it's slightly out of synch but this problem is handled by `other-window-for-scrolling'. But you probably should try to find out why it has been designed this way and/or propose an appropriate fix for the completions code. martin