bug#13898: 24.3.50; Non-cycle completion can use the wrong window

[Jorgen Schaefer]

Hello!

When using `completion-at-point' (or any minibuffer completion), the
completion can scroll a window different from the completions.


Reproduction:

1) Create three windows using C-x 2, let's call them A, B and C from top
to bottom.

2) Make sure all three of them are at the top of the buffer and have
more text in them than fits in them (i.e. can be scrolled up; down; er;
text can scroll up).

3) Start ielm (M-x ielm) in the bottommost. This is just to get a buffer
in which tab completion happens, as opposed to the minibuffer.

4) Go to the topmost window, A. Then switch directly to the bottommost,
i.e. switch to C so that A is still the "other" window. E.g. using M-:
(select-window (nth 2 (window-list)))

5) Start a completion, e.g. using f TAB. A completion buffer shows up in
window *B*. Hit TAB again. Notice that window *A* is cycling.


The problem is that `minibuffer-complete' calls `scroll-other-window'
even though that's not the correct window in this case.

Trivial fix:

--- lisp/minibuffer.el  2013-02-09 05:52:20 +0000
+++ lisp/minibuffer.el  2013-03-07 19:58:39 +0000
@@ -1050,7 +1050,8 @@
             ;; If end is in view, scroll up to the beginning.
             (set-window-start window (point-min) nil)
           ;; Else scroll down one screen.
-          (scroll-other-window))
+          (with-selected-window window
+            (scroll-up)))
         nil)))
    ;; If we're cycling, keep on cycling.
    ((and completion-cycling completion-all-sorted-completions)


Regards,
        -- Jorgen

PS. Not a regression, 24.2 already had this bug.


In GNU Emacs 24.3.50.1 (x86_64-unknown-linux-gnu)
 of 2013-03-02 on orion.kollektiv-hamburg.de
Bzr revision: 111915 rgm@gnu.org-20130302111734-5qg3o3o84z1dxzdy
Configured using:
 `configure --without-x --with-x-toolkit=no'