GNU bug report logs - #16909
24.3; scrolling *Completions* window with tab sometimes chooses a wrong window

Previous Next

Full log

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

From: martin rudalics <rudalics <at> gmx.at>
To: Lukasz Pawelczyk <havner <at> gmail.com>
Cc: "16909 <at> debbugs.gnu.org" <16909 <at> debbugs.gnu.org>
Subject: Re: bug#16909: 24.3; scrolling *Completions* window with tab sometimes
 chooses a wrong window
Date: Wed, 05 Mar 2014 08:26:52 +0100

>> We have to detect the moment when the window is closed automatically
>> anyway.  At that time we can either kill the buffer or reset
>> `other-window-scroll-buffer’.
>
> I’m still not sure that even using this variable is a wise idea. It might be used
> by a user to configure his things.

By design it's a plain variable and not a user option.

> A simple custom function that will always scroll
> *Completions* window seems like a better choice. You can always scroll
> by buffer name. No need to force the usage of scroll-other-window function.

IIRC the initial intention was to make the *Completions* window the
`next-window' so it would get scrolled automatically by C-M-v.  When
that failed, `other-window-scroll-buffer' was invented to handle the
case where the *Completions* window was not the next window.  I doubt
that a custom function would gain anything in this regard - it would
still have to find the window to scroll and detect when it's no more
needed.

Which obviously does not preclude the use of a function as value of
`other-window-scroll-buffer'.  Sooner or later we should move
`other-window-for-scrolling' and `scroll-other-window' to Elisp anyway,
so this should be easily doable.

> I meant that if you only kill the buffer (after we used autocomplete) and
> then user will scroll-other-window (for whatever reason) it won’t behave as
> if its value is nil. We’d have to make it nil as well (as you mentioned now).

Why?  If `other-window-scroll-buffer' denotes a dead buffer, it now
should be tantamount to nil.  Or am I missing something?

> If I had an idea where to start I would have sent a patch instead of reporting a bug :-/

I thought you had because you earlier said that

   All of this happens because a window that's chosen for displaying a window
   for completion is created with 'display-buffer', while the window that is
   scrolled with TAB during completion is choosen with a 'other-window'
   ('scroll-other-window') function. And as shown here those windows are not
   always the same.

which gave me the impression that you already did some preliminary
investigative work.

martin

Previous Next

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