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

[Lukasz Pawelczyk <havner@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3008 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 4185 bytes --]