bug#16909: 24.3; scrolling *Completions* window with tab sometimes chooses a wrong window

[Lukasz Pawelczyk]

On Wed, Mar 5, 2014 at 8:26 AM, martin rudalics <rudalics@gmx.at> wrote:

>> 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.

In that case it's ok.

 

> 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.

If that's the case, sure.

> 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 the 'other-window-scroll-buffer' is pointing to a dead buffer 'scroll-other-window'

does not fallback to its normal behaviour. You get an 'invalid buffer' message.

So we don't have to kill the *Completions* buffer. We need to set the variable back

to nil to resume normal user operations after using auto complete scrolling.

> 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.

My investigation was to figure out what is going on, not precisely where to fix it and was

based on semantic's autocomplete which behaves exactly the same. I just thought

that reporting this in base emacs functionality might get a higher chance to get

attention. And the mechanism and a cause seems to be exactly the same.

I didn't manage to pinpoint where it happens in case of elisp auto complete.

Only for semantic displayor one (which needs fixing as well).

 

--
Regards
Havner