GNU bug report logs - #13898
24.3.50; Non-cycle completion can use the wrong window

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 13898 in the body.
You can then email your comments to 13898 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jorgen Schaefer <forcer <at> forcix.cx>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.50; Non-cycle completion can use the wrong window
Date: Thu, 07 Mar 2013 21:12:46 +0100

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 <at> gnu.org-20130302111734-5qg3o3o84z1dxzdy
Configured using:
 `configure --without-x --with-x-toolkit=no'

Message #8 received at 13898 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Jorgen Schaefer <forcer <at> forcix.cx>
Cc: 13898 <at> debbugs.gnu.org
Subject: Re: bug#13898: 24.3.50; Non-cycle completion can use the wrong window
Date: Sun, 17 Mar 2013 18:21:41 -0400

>              ;; 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)))

Looks good, please install,


        Stefan

Message #13 received at 13898-done <at> debbugs.gnu.org (full text, mbox):

From: Jorgen Schaefer <contact <at> jorgenschaefer.de>
To: 13898-done <at> debbugs.gnu.org
Subject: Re: 24.3.50; Non-cycle completion can use the wrong window
Date: Sun, 24 Nov 2013 15:39:26 +0100

Patch applied in revno 115210.

Regards,
Jorgen

Message #16 received at 13898 <at> debbugs.gnu.org (full text, mbox):

From: Ivan Shmakov <ivan <at> siamics.net>
To: 13898 <at> debbugs.gnu.org, control <at> debbugs.gnu.org
Subject: [babc40c4] minibuffer-complete does not cycle anymore 
Date: Mon, 02 Dec 2013 19:15:34 +0000

reopen 13898
thanks

	… It may be due to a different bug, but as of babc40c41c5c,
	minibuffer-complete does not cycle anymore.

	Example: C-h f TAB TAB TAB… – the TABs after the first seem to
	have no visible effect whatsoever.

	Since reverting the change made in 35b3f07859c4 restores the
	proper minibuffer-complete behavior, I took the liberty to
	reopen #13898.  (Feel free to clone and close it if necessary.)

-- 
FSF associate member #7257

Message #23 received at 13898-done <at> debbugs.gnu.org (full text, mbox):

From: Ivan Shmakov <ivan <at> siamics.net>
To: 13898-done <at> debbugs.gnu.org
Subject: Re: [babc40c4] minibuffer-complete does not cycle anymore
Date: Thu, 05 Dec 2013 19:21:47 +0000

>>>>> Ivan Shmakov <ivan <at> siamics.net> writes:

 > reopen 13898 thanks

 > … It may be due to a different bug, but as of babc40c41c5c,
 > minibuffer-complete does not cycle anymore.

	And even quite likely so, as as of 0dd4ebbcf94d, it all seem to
	work correctly.

	Sorry for the noise, closing this one back.

 > Example: C-h f TAB TAB TAB… – the TABs after the first seem to have
 > no visible effect whatsoever.

 > Since reverting the change made in 35b3f07859c4 restores the proper
 > minibuffer-complete behavior, I took the liberty to reopen #13898.
 > (Feel free to clone and close it if necessary.)

-- 
FSF associate member #7257

Message #26 received at 13898 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: 13898 <at> debbugs.gnu.org
Cc: ivan <at> siamics.net, forcer <at> forcix.cx
Subject: Re: bug#13898: [babc40c4] minibuffer-complete does not cycle anymore
Date: Thu, 05 Dec 2013 15:12:11 -0500

>> … It may be due to a different bug, but as of babc40c41c5c,
>> minibuffer-complete does not cycle anymore.
> 	And even quite likely so, as as of 0dd4ebbcf94d, it all seem to
> 	work correctly.

I don't know what those rev-ids correspond to, but... I'm glad it all
works out ;-)


        Stefan

Message #29 received at 13898 <at> debbugs.gnu.org (full text, mbox):

From: Ivan Shmakov <ivan <at> siamics.net>
To: 13898 <at> debbugs.gnu.org
Subject: Re: bug#13898: [babc40c4] minibuffer-complete does not cycle anymore
Date: Fri, 06 Dec 2013 18:19:25 +0000

>>>>> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

 >>> … It may be due to a different bug, but as of babc40c41c5c,
 >>> minibuffer-complete does not cycle anymore.

 >> And even quite likely so, as as of 0dd4ebbcf94d, it all seem to work
 >> correctly.

 > I don't know what those rev-ids correspond to, but...  I'm glad it
 > all works out ;-)

	JFTR:

http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=babc40c41c5c
http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=0dd4ebbcf94d

-- 
FSF associate member #7257

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.