[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#16909: 24.3; scrolling *Completions* window with tab sometimes choos
From: |
martin rudalics |
Subject: |
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
- bug#16909: 24.3; scrolling *Completions* window with tab sometimes chooses a wrong window, martin rudalics, 2014/03/01
- bug#16909: 24.3; scrolling *Completions* window with tab sometimes chooses a wrong window, Lukasz Pawelczyk, 2014/03/01
- bug#16909: 24.3; scrolling *Completions* window with tab sometimes chooses a wrong window, martin rudalics, 2014/03/01
- bug#16909: 24.3; scrolling *Completions* window with tab sometimes chooses a wrong window, Lukasz Pawelczyk, 2014/03/04
- bug#16909: 24.3; scrolling *Completions* window with tab sometimes chooses a wrong window,
martin rudalics <=
- bug#16909: 24.3; scrolling *Completions* window with tab sometimes chooses a wrong window, Lukasz Pawelczyk, 2014/03/05
- bug#16909: 24.3; scrolling *Completions* window with tab sometimes chooses a wrong window, martin rudalics, 2014/03/05
- bug#16909: 24.3; scrolling *Completions* window with tab sometimes chooses a wrong window, Lukasz Pawelczyk, 2014/03/06
- bug#16909: 24.3; scrolling *Completions* window with tab sometimes chooses a wrong window, martin rudalics, 2014/03/06