From unknown Tue Jun 24 22:40:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8358: 24.0.50; `minibuffer-scroll-window' with active minibuffer: always *Completions*? 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: Sun, 27 Mar 2011 22:04:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 8358 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 8358@debbugs.gnu.org X-Debbugs-Original-To: Received: via spool by submit@debbugs.gnu.org id=B.130126341028413 (code B ref -1); Sun, 27 Mar 2011 22:04:02 +0000 Received: (at submit) by debbugs.gnu.org; 27 Mar 2011 22:03:30 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Q3y3V-0007OE-Ux for submit@debbugs.gnu.org; Sun, 27 Mar 2011 18:03:30 -0400 Received: from eggs.gnu.org ([140.186.70.92]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Q3y3T-0007O2-FV for submit@debbugs.gnu.org; Sun, 27 Mar 2011 18:03:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q3y3N-0000Op-JO for submit@debbugs.gnu.org; Sun, 27 Mar 2011 18:03:22 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 Received: from lists.gnu.org ([199.232.76.165]:60553) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q3y3N-0000Ok-Gj for submit@debbugs.gnu.org; Sun, 27 Mar 2011 18:03:21 -0400 Received: from [140.186.70.92] (port=47223 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q3y3M-0008Dr-3B for bug-gnu-emacs@gnu.org; Sun, 27 Mar 2011 18:03:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q3y3L-0000OD-Br for bug-gnu-emacs@gnu.org; Sun, 27 Mar 2011 18:03:20 -0400 Received: from rcsinet10.oracle.com ([148.87.113.121]:45148) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q3y3L-0000Ns-00 for bug-gnu-emacs@gnu.org; Sun, 27 Mar 2011 18:03:19 -0400 Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p2RM3GHK015274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 27 Mar 2011 22:03:17 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p2RM3Fxa022781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 27 Mar 2011 22:03:16 GMT Received: from abhmt015.oracle.com (abhmt015.oracle.com [141.146.116.24]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p2RM3FIr022516 for ; Sun, 27 Mar 2011 17:03:15 -0500 Received: from dradamslap1 (/10.159.60.136) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 27 Mar 2011 15:03:14 -0700 From: "Drew Adams" Date: Sun, 27 Mar 2011 15:03:17 -0700 Message-ID: <85A4B6FC9D55449098D84231439FAF9B@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acvsysb2Kb1QQy2uSXKaEABW1LTw/Q== 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.0A090202.4D8FB424.0021,ss=1,fgs=0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 199.232.76.165 X-Spam-Score: -6.4 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.4 (------) `minibuffer-scroll-window' is the window to be scrolled by `scroll-other-window' from the minibuffer. The doc suggests that setting `minibuffer-scroll-window' to some window when the minibuffer is active would make other-window scrolling use that window. E.g. the doc for `scroll-other-window' includes this: "If in the minibuffer, `minibuffer-scroll-window' if non-nil specifies the window to scroll. This takes precedence over `other-window-scroll-buffer'." It doesn't say that the *Completions* window is always the other window scrolled. But `minibuffer-scroll-window' always seems to be reset to the *Completions* window, AFAICT. Help me understand how to make some other window than the *Completions* window the target to be scrolled by `scroll-other-window' from the minibuffer. emacs -Q C-x d RET C-x 4 b *scratch* RET (defun foo () (setq minibuffer-scroll-window (get-buffer-window (get-buffer "*scratch*") 0)) (message "fffff, MSW: %S" minibuffer-scroll-window) (sleep-for 2)) (add-hook 'completion-setup-hook 'foo 'append) (defun bar (arg) (interactive "P") (message "BBBBB, MSW: %S" minibuffer-scroll-window) (sleep-for 2) (scroll-other-window arg)) (define-key minibuffer-local-completion-map "\C-\M-v" 'bar) Return focus to the Dired window. M-x for TAB C-M-v That shows that `minibuffer-scroll-window' is the *Completions* window when `C-M-v' is pressed, even though `minibuffer-scroll-window' was the *scratch* window just after *Completions* was shown. I looked at the code in minibuffer.el and window.c to try to understand where `minibuffer-scroll-window' is getting reset (to *Completions*), but I haven't understood, so far. (`minibuffer-complete' does set `minibuffer-scroll-window' (e.g. to nil), but debugging that function shows that it doesn't seem to make a difference here. And my own code, where I also see the problem, doesn't even call `minibuffer-complete'.) Help appreciated. Is this a bug? Shouldn't you be able to set the window to be scrolled (using `scroll-other-window') during minibuffer input to be some window other than *Completions*? How can I do that? Just where is `minibuffer-scroll-window' getting set and reset? Thx. In GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600) of 2011-03-21 on 3249CTO Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (4.5) --no-opt --cflags -Ic:/imagesupport/include' From unknown Tue Jun 24 22:40:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8358: 24.0.50; `minibuffer-scroll-window' with active minibuffer: always *Completions*? 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 06:35:01 +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: To: Drew Adams Cc: 8358@debbugs.gnu.org Received: via spool by 8358-submit@debbugs.gnu.org id=B8358.130129407712341 (code B ref 8358); Mon, 28 Mar 2011 06:35:01 +0000 Received: (at 8358) by debbugs.gnu.org; 28 Mar 2011 06:34:37 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Q4627-0003D0-SV for submit@debbugs.gnu.org; Mon, 28 Mar 2011 02:34:36 -0400 Received: from mailout-de.gmx.net ([213.165.64.23]) by debbugs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1Q4624-0003Cj-A9 for 8358@debbugs.gnu.org; Mon, 28 Mar 2011 02:34:34 -0400 Received: (qmail invoked by alias); 28 Mar 2011 06:34:25 -0000 Received: from 62-47-38-45.adsl.highway.telekom.at (EHLO [62.47.38.45]) [62.47.38.45] by mail.gmx.net (mp069) with SMTP; 28 Mar 2011 08:34:25 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/lvssSRDXlUuJ5aOkIy/IESK1M39ZiqUzPmFics3 fDqJfaEdTiro3l Message-ID: <4D902BEF.7050107@gmx.at> Date: Mon, 28 Mar 2011 08:34:23 +0200 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 References: <85A4B6FC9D55449098D84231439FAF9B@us.oracle.com> In-Reply-To: <85A4B6FC9D55449098D84231439FAF9B@us.oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -2.5 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.5 (--) > I looked at the code in minibuffer.el and window.c to try to understand > where `minibuffer-scroll-window' is getting reset (to *Completions*), > but I haven't understood, so far. `with-output-to-temp-buffer' which displays the *Completions* buffer sets `minibuffer-scroll-window' to the window showing *Completions*. This happens _after_ running `completion-setup-hook' so your "foo" doesn't really do what you expected. > Help appreciated. Is this a bug? Shouldn't you be able to set the > window to be scrolled (using `scroll-other-window') during minibuffer > input to be some window other than *Completions*? How can I do that? > Just where is `minibuffer-scroll-window' getting set and reset? Thx. Try doing (add-hook 'temp-buffer-show-hook 'foo 'append) instead. Or write your own `temp-buffer-show-function'. martin From unknown Tue Jun 24 22:40:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8358: 24.0.50; `minibuffer-scroll-window' with active minibuffer: always *Completions*? 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: Mon, 28 Mar 2011 13:46: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: To: "'martin rudalics'" Cc: 8358@debbugs.gnu.org Received: via spool by 8358-submit@debbugs.gnu.org id=B8358.130131990819362 (code B ref 8358); Mon, 28 Mar 2011 13:46:02 +0000 Received: (at 8358) by debbugs.gnu.org; 28 Mar 2011 13:45:08 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Q4Ckl-00052F-35 for submit@debbugs.gnu.org; Mon, 28 Mar 2011 09:45:07 -0400 Received: from rcsinet10.oracle.com ([148.87.113.121]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Q4Ckh-00051V-QD for 8358@debbugs.gnu.org; Mon, 28 Mar 2011 09:45:04 -0400 Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p2SDitDX010812 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 28 Mar 2011 13:44:57 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p2SDisLo004323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Mar 2011 13:44:54 GMT Received: from abhmt003.oracle.com (abhmt003.oracle.com [141.146.116.12]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p2SDisNS024372; Mon, 28 Mar 2011 08:44:54 -0500 Received: from dradamslap1 (/10.159.60.136) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 28 Mar 2011 06:44:53 -0700 From: "Drew Adams" References: <85A4B6FC9D55449098D84231439FAF9B@us.oracle.com> <4D902BEF.7050107@gmx.at> Date: Mon, 28 Mar 2011 06:44:55 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4D902BEF.7050107@gmx.at> Thread-Index: AcvtEjCOyV4xK+VKTzaUc0gUAUF2xwAOBjRg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 X-Source-IP: acsmt357.oracle.com [141.146.40.157] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4D9090D7.005B,ss=1,fgs=0 X-Spam-Score: -6.4 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.4 (------) > `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. > This happens _after_ running `completion-setup-hook' so your "foo" > doesn't really do what you expected. > > > Shouldn't you be able to set the window to be scrolled > > (using `scroll-other-window') during minibuffer > > input to be some window other than *Completions*? How can > > I do that? > > 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. `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. 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*? 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? From unknown Tue Jun 24 22:40:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8358: 24.0.50; `minibuffer-scroll-window' with active minibuffer: always *Completions*? 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: To: Drew Adams Cc: 8358@debbugs.gnu.org Received: via spool by 8358-submit@debbugs.gnu.org id=B8358.130132452929375 (code B ref 8358); Mon, 28 Mar 2011 15:03:02 +0000 Received: (at 8358) by debbugs.gnu.org; 28 Mar 2011 15:02:09 +0000 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 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 Received: (qmail invoked by alias); 28 Mar 2011 15:01:58 -0000 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 Message-ID: <4D90A2E5.9020206@gmx.at> Date: Mon, 28 Mar 2011 17:01:57 +0200 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 References: <85A4B6FC9D55449098D84231439FAF9B@us.oracle.com> <4D902BEF.7050107@gmx.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -2.5 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.5 (--) >> `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 From unknown Tue Jun 24 22:40:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8358: 24.0.50; `minibuffer-scroll-window' with active minibuffer: always *Completions*? 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: Mon, 28 Mar 2011 16:23:01 +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: To: "'martin rudalics'" Cc: 8358@debbugs.gnu.org Received: via spool by 8358-submit@debbugs.gnu.org id=B8358.13013293483743 (code B ref 8358); Mon, 28 Mar 2011 16:23:01 +0000 Received: (at 8358) by debbugs.gnu.org; 28 Mar 2011 16:22:28 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Q4FD1-0000yK-9f for submit@debbugs.gnu.org; Mon, 28 Mar 2011 12:22:27 -0400 Received: from rcsinet10.oracle.com ([148.87.113.121]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Q4FCz-0000y6-Ve for 8358@debbugs.gnu.org; Mon, 28 Mar 2011 12:22:26 -0400 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 p2SGMIjl010325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 28 Mar 2011 16:22:19 GMT 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 p2SGMHLS014773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Mar 2011 16:22:17 GMT Received: from abhmt009.oracle.com (abhmt009.oracle.com [141.146.116.18]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p2SGMGnP017714; Mon, 28 Mar 2011 11:22:16 -0500 Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 28 Mar 2011 09:22:14 -0700 From: "Drew Adams" References: <85A4B6FC9D55449098D84231439FAF9B@us.oracle.com> <4D902BEF.7050107@gmx.at> <4D90A2E5.9020206@gmx.at> Date: Mon, 28 Mar 2011 09:22:13 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <4D90A2E5.9020206@gmx.at> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Thread-Index: AcvtWRiNHN4ShNuNQsuio68aeIAYkAAAWzdQ X-Source-IP: acsmt356.oracle.com [141.146.40.156] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4D90B5B9.0132,ss=1,fgs=0 X-Spam-Score: -6.4 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.4 (------) > `minibuffer-scroll-window' is not a user option. So by design it's a > variable any code is allowed to change. Yes, any code, including user code. And it is explicitly called out in the doc of `scroll-other-window', to let programmers know about it. We don't generally do that for internal variables that are used only to always produce the same visible behavior. Yes, I realize that the window object used for *Completions* changes. But if that were the only reason for this variable then I doubt that it would figure in the user documentation. > 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. Your "because" has nothing to do with the clause it is applied to (AFAICT). That the caller of `with-output-to-temp-buffer' might not know which window displays the temp buffer is not a reason to make the window that is to be scrolled always be the *Completions* window. That just doesn't follow. > `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. It won't do the job needed anyway. In a single minibuffer input reading I dynamically update the set of matching completions according to what the user types (similar to the incremental completion of ido or icomplete, but using *Completions*). Depending on what the user does (e.g., particular minibuffer keys s?he hits), the "other" window to be scrolled needs to change. Think, for example, of a minibuffer key that displays some information in another window, which the user might then want to scroll. I would like to set `minibuffer-scroll-window' to that window (whatever it might be, depending on the context). But when I do that `minibuffer-scroll-window' keeps getting reset to the *Completions* window (presumably because updating the set of matching completions redisplays *Completions*). > I'm only trying to explain what happens I appreciate that; thank you. > 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. You mean because *Completions* is in fact the window that gets scrolled? That's putting the cart a bit before the horse. As I said, if the intention were only that *Completions* should always be scrolled, then the doc would say so: in the minibuffer, the *Completions* window is the other window scrolled. It could add that the *Completions* window is the value of `minibuffer-scroll-window' (but it need not even bother). If that were the intention then the doc for `minibuffer-scroll-window' would simply say that it is the *Completions* window, which you can scroll from the minibuffer using C-M-v. And the variable might as well be named something like `completions-window' in that case. But that is not at all what the doc indicates. It suggests strongly that `minibuffer-scroll-window' can be set to control which window gets scrolled. > 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. I guess I'll just forget about `minibuffer-scroll-window' and `scroll-other-window', and simply roll my own command that scrolls the window that I tell it too. If Emacs Dev is not interested in fixing this, so be it. From unknown Tue Jun 24 22:40:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8358: 24.0.50; `minibuffer-scroll-window' with active minibuffer: always *Completions*? 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 18:52: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: To: Drew Adams Cc: 8358@debbugs.gnu.org Received: via spool by 8358-submit@debbugs.gnu.org id=B8358.130133828917422 (code B ref 8358); Mon, 28 Mar 2011 18:52:02 +0000 Received: (at 8358) by debbugs.gnu.org; 28 Mar 2011 18:51:29 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Q4HXE-0004Ww-LW for submit@debbugs.gnu.org; Mon, 28 Mar 2011 14:51:28 -0400 Received: from mailout-de.gmx.net ([213.165.64.23]) by debbugs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1Q4HXA-0004Wi-Uf for 8358@debbugs.gnu.org; Mon, 28 Mar 2011 14:51:26 -0400 Received: (qmail invoked by alias); 28 Mar 2011 18:51:18 -0000 Received: from 62-47-42-27.adsl.highway.telekom.at (EHLO [62.47.42.27]) [62.47.42.27] by mail.gmx.net (mp065) with SMTP; 28 Mar 2011 20:51:18 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1+Vkj5xPT2VpqrjvQydaN/OOas+xgOV7vYBG+tDXl oyj2lHdt8y/1A4 Message-ID: <4D90D8A4.6020900@gmx.at> Date: Mon, 28 Mar 2011 20:51:16 +0200 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 References: <85A4B6FC9D55449098D84231439FAF9B@us.oracle.com> <4D902BEF.7050107@gmx.at> <4D90A2E5.9020206@gmx.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -2.5 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.5 (--) >> `minibuffer-scroll-window' is not a user option. So by design it's a >> variable any code is allowed to change. > > Yes, any code, including user code. And it is explicitly called out in the doc > of `scroll-other-window', to let programmers know about it. We don't generally > do that for internal variables that are used only to always produce the same > visible behavior. I still don't understand why you can't or don't want to change it in your code. Or did I miss something? > Yes, I realize that the window object used for *Completions* changes. But if > that were the only reason for this variable then I doubt that it would figure in > the user documentation. > >> 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. > > Your "because" has nothing to do with the clause it is applied to (AFAICT). > That the caller of `with-output-to-temp-buffer' might not know which window > displays the temp buffer is not a reason to make the window that is to be > scrolled always be the *Completions* window. That just doesn't follow. Why do you use the term "always" here? `minibuffer-scroll-window' is set to the window used for displaying the temporary buffer which can be *Completions* or *Help* or whatever you have. >> `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. > > It won't do the job needed anyway. It will do the job for this particular case. > In a single minibuffer input reading I > dynamically update the set of matching completions according to what the user > types (similar to the incremental completion of ido or icomplete, but using > *Completions*). > > Depending on what the user does (e.g., particular minibuffer keys s?he hits), > the "other" window to be scrolled needs to change. Think, for example, of a > minibuffer key that displays some information in another window, which the user > might then want to scroll. > > I would like to set `minibuffer-scroll-window' to that window (whatever it might > be, depending on the context). But when I do that `minibuffer-scroll-window' > keeps getting reset to the *Completions* window (presumably because updating the > set of matching completions redisplays *Completions*). So define a variable `my-minibuffer-scroll-window' and whenever `with-output-to-temp-buffer' steals the window from you reset `minibuffer-scroll-window' to `my-minibuffer-scroll-window' in `temp-buffer-show-hook'. >> 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. > > You mean because *Completions* is in fact the window that gets scrolled? That's > putting the cart a bit before the horse. I don't follow you here. What would you tell people using your code when they complain that you set `minibuffer-scroll-window' to a window they don't want to scroll? > As I said, if the intention were only that *Completions* should always be > scrolled, then the doc would say so: in the minibuffer, the *Completions* window > is the other window scrolled. It could add that the *Completions* window is the > value of `minibuffer-scroll-window' (but it need not even bother). The only doc that could be fixed in this respect is that of `with-output-to-temp-buffer'. > If that were the intention then the doc for `minibuffer-scroll-window' would > simply say that it is the *Completions* window, which you can scroll from the > minibuffer using C-M-v. And the variable might as well be named something like > `completions-window' in that case. But every window used by `with-output-to-temp-buffer' is affected, not only the *Completions* window. > But that is not at all what the doc indicates. It suggests strongly that > `minibuffer-scroll-window' can be set to control which window gets scrolled. It can. `with-output-to-temp-buffer' makes use of that property. And you can override it in `temp-buffer-show-hook'. martin From unknown Tue Jun 24 22:40:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8358: 24.0.50; `minibuffer-scroll-window' with active minibuffer: always *Completions*? 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: Mon, 28 Mar 2011 20:02:01 +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: To: "'martin rudalics'" Cc: 8358@debbugs.gnu.org Received: via spool by 8358-submit@debbugs.gnu.org id=B8358.130134246725645 (code B ref 8358); Mon, 28 Mar 2011 20:02:01 +0000 Received: (at 8358) by debbugs.gnu.org; 28 Mar 2011 20:01:07 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Q4Icd-0006fa-60 for submit@debbugs.gnu.org; Mon, 28 Mar 2011 16:01:07 -0400 Received: from rcsinet10.oracle.com ([148.87.113.121]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Q4Ica-0006ew-Fe for 8358@debbugs.gnu.org; Mon, 28 Mar 2011 16:01:05 -0400 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 p2SK0vdl015408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 28 Mar 2011 20:00:58 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p2SK0tcV009057 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Mar 2011 20:00:56 GMT Received: from abhmt021.oracle.com (abhmt021.oracle.com [141.146.116.30]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p2SK0t89025629; Mon, 28 Mar 2011 15:00:55 -0500 Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 28 Mar 2011 13:00:54 -0700 From: "Drew Adams" References: <85A4B6FC9D55449098D84231439FAF9B@us.oracle.com> <4D902BEF.7050107@gmx.at> <4D90A2E5.9020206@gmx.at> <4D90D8A4.6020900@gmx.at> Date: Mon, 28 Mar 2011 13:00:55 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <4D90D8A4.6020900@gmx.at> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Thread-Index: AcvteSGOtfGZpqsqTRy2wGybSID4BQACAJRg X-Source-IP: acsmt358.oracle.com [141.146.40.158] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4D90E8F8.00E6,ss=1,fgs=0 X-Spam-Score: -6.4 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.4 (------) > I still don't understand why you can't or don't want to change it in > your code. Or did I miss something? I don't see an easy fix. See what I said about incremental completion etc., if you're interested. > > Your "because" has nothing to do with the clause it is > > applied to (AFAICT). That the caller of > > `with-output-to-temp-buffer' might not know which window > > displays the temp buffer is not a reason to make the > > window that is to be scrolled always be the *Completions* > > window. That just doesn't follow. > > Why do you use the term "always" here? `minibuffer-scroll-window' is > set to the window used for displaying the temporary buffer > which can be *Completions* or *Help* or whatever you have. Whenever the minibuffer is used for completion, and *Completions* is displayed, it is automatically set to the *Completions* window. So not quite always, since you can use the minibuffer without completion. > > I would like to set `minibuffer-scroll-window' to that > > window (whatever it might be, depending on the context). > > But when I do that `minibuffer-scroll-window' > > keeps getting reset to the *Completions* window > > (presumably because updating the > > set of matching completions redisplays *Completions*). > > So define a variable `my-minibuffer-scroll-window' and whenever > `with-output-to-temp-buffer' steals the window from you reset > `minibuffer-scroll-window' to `my-minibuffer-scroll-window' in > `temp-buffer-show-hook'. If `temp-buffer-show-hook' is the only culprit, then that might be a workaround. One way or another I will find a solution for myself (the easiest thing is to just define a new scroll command that respects a new variable). That doesn't change the fact (IMO) that this behavior represents a bug. > I don't follow you here. What would you tell people using your code > when they complain that you set `minibuffer-scroll-window' to a window > they don't want to scroll? Users of my code already scroll *Completions* using different keys (which invokes different code), anyway. And they would appreciate being able to scroll the other windows they interact with during completion. > The only doc that could be fixed in this respect is that of > `with-output-to-temp-buffer'. > > But that is not at all what the doc indicates. It > > suggests strongly that `minibuffer-scroll-window' can be > > set to control which window gets scrolled. > > It can. `with-output-to-temp-buffer' makes use of that property. And > you can override it in `temp-buffer-show-hook'. Should be able to set it at any time and have it take effect (not be wiped out by `with-output-to-temp-buffer'. Anyway, it's clear we don't agree. The simple solution (trivial in this case) is for me to just roll my own and forget about using `scroll-other-window(-down)' and `minibuffer-scroll-window', since they are essentially hard-coded during completion. From unknown Tue Jun 24 22:40:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8358: 24.0.50; `minibuffer-scroll-window' with active minibuffer: always *Completions*? Resent-From: Stefan Monnier 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 00:32: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: To: "Drew Adams" Cc: 'martin rudalics' , 8358@debbugs.gnu.org Received: via spool by 8358-submit@debbugs.gnu.org id=B8358.130135868318599 (code B ref 8358); Tue, 29 Mar 2011 00:32:02 +0000 Received: (at 8358) by debbugs.gnu.org; 29 Mar 2011 00:31:23 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Q4MqA-0004pw-Dv for submit@debbugs.gnu.org; Mon, 28 Mar 2011 20:31:22 -0400 Received: from pruche.dit.umontreal.ca ([132.204.246.22]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Q4Mq7-0004pU-3b for 8358@debbugs.gnu.org; Mon, 28 Mar 2011 20:31:19 -0400 Received: from ceviche.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id p2T0VCVI014048; Mon, 28 Mar 2011 20:31:12 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 1C18C660C7; Mon, 28 Mar 2011 11:07:51 -0400 (EDT) From: Stefan Monnier Message-ID: References: <85A4B6FC9D55449098D84231439FAF9B@us.oracle.com> <4D902BEF.7050107@gmx.at> Date: Mon, 28 Mar 2011 11:07:51 -0400 In-Reply-To: (Drew Adams's message of "Mon, 28 Mar 2011 06:44:55 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV3810=0 X-NAI-Spam-Version: 2.2.0.9286 : core <3810> : streams <614376> : uri <837528> X-Spam-Score: -1.5 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.5 (-) > 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. > 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 ...". Stefan From unknown Tue Jun 24 22:40:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8358: 24.0.50; `minibuffer-scroll-window' with active minibuffer: always *Completions*? Resent-From: Stefan Monnier 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 01:06: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: To: "Drew Adams" Cc: 'martin rudalics' , 8358@debbugs.gnu.org Received: via spool by 8358-submit@debbugs.gnu.org id=B8358.130136075721620 (code B ref 8358); Tue, 29 Mar 2011 01:06:02 +0000 Received: (at 8358) by debbugs.gnu.org; 29 Mar 2011 01:05:57 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Q4NNc-0005cf-Ts for submit@debbugs.gnu.org; Mon, 28 Mar 2011 21:05:57 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.183] helo=ironport2-out.pppoe.ca) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Q4NNa-0005cR-Pq for 8358@debbugs.gnu.org; Mon, 28 Mar 2011 21:05:55 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADEvkU1MCqRC/2dsb2JhbAClR3iIdrxUhWoElgY X-IronPort-AV: E=Sophos;i="4.63,259,1299474000"; d="scan'208";a="98439934" Received: from 76-10-164-66.dsl.teksavvy.com (HELO ceviche.home) ([76.10.164.66]) by ironport2-out.pppoe.ca with ESMTP/TLS/ADH-AES256-SHA; 28 Mar 2011 21:05:48 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 7D4B9660C7; Mon, 28 Mar 2011 21:05:48 -0400 (EDT) From: Stefan Monnier Message-ID: References: <85A4B6FC9D55449098D84231439FAF9B@us.oracle.com> <4D902BEF.7050107@gmx.at> <4D90A2E5.9020206@gmx.at> <4D90D8A4.6020900@gmx.at> Date: Mon, 28 Mar 2011 21:05:48 -0400 In-Reply-To: (Drew Adams's message of "Mon, 28 Mar 2011 13:00:55 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.1 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.1 (--) > Should be able to set it at any time and have it take effect (not be > wiped out by `with-output-to-temp-buffer'. Anyway, it's clear we > don't agree. The simple solution (trivial in this case) is for me to > just roll my own and forget about using `scroll-other-window(-down)' > and `minibuffer-scroll-window', since they are essentially hard-coded > during completion. Here's my question: given that we want (by default) scroll-other-window to scroll the *Completions* buffer when called from the minibuffer and *Completions* has been displayed, how else would you implement this in a way that also satisfies your needs? IOW send us some kind of patch to the Emacs code that does not change the current default behavior, but makes it flexible in the way you expect. Stefan From unknown Tue Jun 24 22:40:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8358: 24.0.50; `minibuffer-scroll-window' with active minibuffer: always *Completions*? 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: To: "'Stefan Monnier'" Cc: 'martin rudalics' , 8358@debbugs.gnu.org Received: via spool by 8358-submit@debbugs.gnu.org id=B8358.130137204910958 (code B ref 8358); Tue, 29 Mar 2011 04:15:02 +0000 Received: (at 8358) by debbugs.gnu.org; 29 Mar 2011 04:14:09 +0000 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 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 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 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 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 Received: from dradamslap1 (/10.159.58.135) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 28 Mar 2011 21:13:57 -0700 From: "Drew Adams" References: <85A4B6FC9D55449098D84231439FAF9B@us.oracle.com><4D902BEF.7050107@gmx.at> Date: Mon, 28 Mar 2011 21:13:56 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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-Spam-Score: -6.4 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.4 (------) > > 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. From unknown Tue Jun 24 22:40:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8358: 24.0.50; `minibuffer-scroll-window' with active minibuffer: always *Completions*? 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: Tue, 29 Mar 2011 09:17:03 +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: To: Drew Adams Cc: 8358@debbugs.gnu.org, 'Stefan Monnier' Received: via spool by 8358-submit@debbugs.gnu.org id=B8358.13013901893897 (code B ref 8358); Tue, 29 Mar 2011 09:17:03 +0000 Received: (at 8358) by debbugs.gnu.org; 29 Mar 2011 09:16:29 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Q4V2L-00010o-IR for submit@debbugs.gnu.org; Tue, 29 Mar 2011 05:16:29 -0400 Received: from mailout-de.gmx.net ([213.165.64.23]) by debbugs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1Q4V2K-00010T-7v for 8358@debbugs.gnu.org; Tue, 29 Mar 2011 05:16:28 -0400 Received: (qmail invoked by alias); 29 Mar 2011 09:16:21 -0000 Received: from 62-47-60-40.adsl.highway.telekom.at (EHLO [62.47.60.40]) [62.47.60.40] by mail.gmx.net (mp041) with SMTP; 29 Mar 2011 11:16:21 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX19LM5M+SNpLuzMXEKACJLKVy1G4gSGYgidNh38BBZ stlXzUCox40tRV Message-ID: <4D919E4D.6060701@gmx.at> Date: Tue, 29 Mar 2011 10:54:37 +0200 From: martin rudalics User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 References: <85A4B6FC9D55449098D84231439FAF9B@us.oracle.com><4D902BEF.7050107@gmx.at> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: -2.5 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.5 (--) >> No, not to "let you ..." but to "let code ...". > > So you are excluding user code. On the contrary. All code is created equal. martin From unknown Tue Jun 24 22:40:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8358: 24.0.50; `minibuffer-scroll-window' with active minibuffer: always *Completions*? 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 14:23:01 +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: To: "'martin rudalics'" Cc: 8358@debbugs.gnu.org, 'Stefan Monnier' Received: via spool by 8358-submit@debbugs.gnu.org id=B8358.1301408570763 (code B ref 8358); Tue, 29 Mar 2011 14:23:01 +0000 Received: (at 8358) by debbugs.gnu.org; 29 Mar 2011 14:22:50 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Q4Zom-0000CG-TN for submit@debbugs.gnu.org; Tue, 29 Mar 2011 10:22:49 -0400 Received: from rcsinet10.oracle.com ([148.87.113.121]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Q4Zok-0000C3-OR for 8358@debbugs.gnu.org; Tue, 29 Mar 2011 10:22:47 -0400 Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p2TEMdce020049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 29 Mar 2011 14:22:41 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p2TEMSfP029681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Mar 2011 14:22:29 GMT Received: from abhmt013.oracle.com (abhmt013.oracle.com [141.146.116.22]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p2TEMSgW017915; Tue, 29 Mar 2011 09:22:28 -0500 Received: from dradamslap1 (/10.159.58.135) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 29 Mar 2011 07:22:27 -0700 From: "Drew Adams" References: <85A4B6FC9D55449098D84231439FAF9B@us.oracle.com><4D902BEF.7050107@gmx.at> <4D919E4D.6060701@gmx.at> Date: Tue, 29 Mar 2011 07:22:25 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4D919E4D.6060701@gmx.at> Thread-Index: Acvt8frALmynP/XkQf67TBbFJWIrhwAKQVhg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 X-Source-IP: acsmt357.oracle.com [141.146.40.157] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A020209.4D91EB2F.00B8,ss=1,fgs=0 X-Spam-Score: -6.4 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.4 (------) > >> No, not to "let you ..." but to "let code ...". > > > > So you are excluding user code. > > On the contrary. All code is created equal. Then Stefan's remark was meaningless. I was obviously talking about user code when I said "let you". Everything I wrote was about doing this from user code. From unknown Tue Jun 24 22:40:07 2025 X-Loop: help-debbugs@gnu.org Subject: bug#8358: 24.0.50; `minibuffer-scroll-window' with active minibuffer: always *Completions*? Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 13 Feb 2022 09:59: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: To: martin rudalics Cc: 8358@debbugs.gnu.org, Drew Adams Received: via spool by 8358-submit@debbugs.gnu.org id=B8358.16447463358478 (code B ref 8358); Sun, 13 Feb 2022 09:59:02 +0000 Received: (at 8358) by debbugs.gnu.org; 13 Feb 2022 09:58:55 +0000 Received: from localhost ([127.0.0.1]:36400 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nJBeh-0002Cf-0T for submit@debbugs.gnu.org; Sun, 13 Feb 2022 04:58:55 -0500 Received: from quimby.gnus.org ([95.216.78.240]:51768) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nJBef-0002CR-0b for 8358@debbugs.gnu.org; Sun, 13 Feb 2022 04:58:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=3DRyFSDI3v7efxMntHfFA3sY9kfPNHX+hC8FME7SzZw=; b=ILYGY6r+LAMSvoQs81QSohJj4y UtJ9Ao154cjz7Zhq/nZ3jNHIxFew52ctTnjEmLSEAS9yWPIwO1D2XSyyLQbfkOFvFHy5Nkb1oOYe/ LJ4LyygiOgAFZNXmhT9YsfNtveZhTq8AtTSqtrGvo8S3+6TWBrbrJF76o3pWvFJKO4e8=; Received: from [84.212.220.105] (helo=giant) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nJBeV-0001bg-AE; Sun, 13 Feb 2022 10:58:46 +0100 From: Lars Ingebrigtsen References: <85A4B6FC9D55449098D84231439FAF9B@us.oracle.com> <4D902BEF.7050107@gmx.at> <4D90A2E5.9020206@gmx.at> X-Now-Playing: Sidsel Endresen & Bugge Wesseltoft's _Out Here. In There._: "Survival Techniques 1+2" Date: Sun, 13 Feb 2022 10:58:42 +0100 In-Reply-To: <4D90A2E5.9020206@gmx.at> (martin rudalics's message of "Mon, 28 Mar 2011 17:01:57 +0200") Message-ID: <87czjrw0j1.fsf_-_@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: martin rudalics writes: > `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 o [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) martin rudalics writes: > `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. Skimming this bug report, it seems like everything is working as designed here, so I'm closing this bug report. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 13 04:59:01 2022 Received: (at control) by debbugs.gnu.org; 13 Feb 2022 09:59:01 +0000 Received: from localhost ([127.0.0.1]:36403 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nJBen-0002Cz-7O for submit@debbugs.gnu.org; Sun, 13 Feb 2022 04:59:01 -0500 Received: from quimby.gnus.org ([95.216.78.240]:51784) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nJBel-0002Cd-1t for control@debbugs.gnu.org; Sun, 13 Feb 2022 04:58:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=bw78HKtB4fFDsVal6+FjKHKVHdDosz+oiX1WtSTlSL8=; b=O3gFyhFGreJ0w59dEUUXZYhqKi kkTB4iSounKY1I3qDrX1L8GNp1y1zDW3tBz8kIG3kwdc5PHfUuxZLnApxO1J86eetOICHQKOBZgyw pzUL2CV7j3rJwFY/FQwU1S4ztGcQry2N+aV37tAVPlNA6jc/F48j80wKUs5zELg1sX0Q=; Received: from [84.212.220.105] (helo=giant) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nJBec-0001bn-CP for control@debbugs.gnu.org; Sun, 13 Feb 2022 10:58:53 +0100 Date: Sun, 13 Feb 2022 10:58:49 +0100 Message-Id: <87bkzbw0iu.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #8358 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: close 8358 quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) close 8358 quit