From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: bug#8358: 24.0.50; `minibuffer-scroll-window' with active minibuffer: always *Completions*? Date: Mon, 28 Mar 2011 21:13:56 -0700 Message-ID: References: <85A4B6FC9D55449098D84231439FAF9B@us.oracle.com><4D902BEF.7050107@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1301373452 5167 80.91.229.12 (29 Mar 2011 04:37:32 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 29 Mar 2011 04:37:32 +0000 (UTC) Cc: 8358@debbugs.gnu.org To: "'Stefan Monnier'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Mar 29 06:37:27 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 1Q4QgI-00021a-Fv for geb-bug-gnu-emacs@m.gmane.org; Tue, 29 Mar 2011 06:37:26 +0200 Original-Received: from localhost ([127.0.0.1]:42941 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q4QgH-000785-UN for geb-bug-gnu-emacs@m.gmane.org; Tue, 29 Mar 2011 00:37:26 -0400 Original-Received: from [140.186.70.92] (port=52578 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q4Qg2-000771-TU for bug-gnu-emacs@gnu.org; Tue, 29 Mar 2011 00:37:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q4Qg1-0005xw-ND for bug-gnu-emacs@gnu.org; Tue, 29 Mar 2011 00:37:10 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:37550) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q4Qg1-0005xs-KJ for bug-gnu-emacs@gnu.org; Tue, 29 Mar 2011 00:37:09 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1Q4QKc-0002sK-9p; Tue, 29 Mar 2011 00:15:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 29 Mar 2011 04:15: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.130137204910958 (code B ref 8358); Tue, 29 Mar 2011 04:15:02 +0000 Original-Received: (at 8358) by debbugs.gnu.org; 29 Mar 2011 04:14: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 1Q4QJk-0002qh-3d for submit@debbugs.gnu.org; Tue, 29 Mar 2011 00:14:08 -0400 Original-Received: from rcsinet10.oracle.com ([148.87.113.121]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Q4QJi-0002qE-TQ for 8358@debbugs.gnu.org; Tue, 29 Mar 2011 00:14:07 -0400 Original-Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p2T4DxSJ007210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 29 Mar 2011 04:14:00 GMT Original-Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p2T4Dw9p005714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Mar 2011 04:13:58 GMT Original-Received: from abhmt001.oracle.com (abhmt001.oracle.com [141.146.116.10]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p2T4Dw2d029365; Mon, 28 Mar 2011 23:13:58 -0500 Original-Received: from dradamslap1 (/10.159.58.135) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 28 Mar 2011 21:13:57 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcvtqKKxCf4L8WD0Tn6LqzfXD6AhKAAFxliw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 X-Source-IP: acsmt356.oracle.com [141.146.40.156] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4D915C87.0053,ss=1,fgs=0 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Tue, 29 Mar 2011 00:15: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:45459 Archived-At: > > Thanks for the info. But why should that happen? > > Because minibuffer.el wants minibuffer-scroll-window to point to > *Completions* after popping up a list of completions. And even if it was already given another window as value, apparently. > > 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. > > No, not to "let you ..." but to "let code ...". So you are excluding user code. OK, your intention is clear. In that case, why document it? The doc gives a completely different impression - it suggests that user code can set this variable to determine which window gets scrolled from the minibuffer by `scroll-other-window'. (And it can, like it or not - except during completion.) And this variable is quite old, certainly much older than the minibuffer.el code that makes one use of it. And it was explicitly exposed to users and documented from the outset (with no exception made for completion). But hey, who said history doesn't allow revision? I do however suggest you change the doc in that case so it fits your intention better. And what do I know anyway? Maybe it never should have been documented; maybe it was always intended as internal-only. Anyway, I got the message; I'll just roll my own here, since `minibuffer-scroll-window' is useless in this context and anyway not intended for user code. That's trivial, and I would have done it from the beginning, but it sounded from the doc like `scroll-other-window' and `minibuffer-scroll-window' were ready-made to scroll a particular window from the minibuffer. Even during completion. Silly me. It seems, in any case, that it is only the use of completion that locks code out from binding/setting the variable usefully. Other uses of the minibuffer pose no such limitation. `widget-choose', for instance, binds the variable on the fly during minibuffer input, but it does not try to do that during completion. So if you change your mind and decide it's OK for user code to use this variable, then you might want to change the doc just a bit to mention that completion is an exception: *Completions* is always the other window to scroll.