bug#8358: 24.0.50; `minibuffer-scroll-window' with active minibuffer: always *Completions*?

[Drew Adams]

> I still don't understand why you can't or don't want to change it in
> your code.  Or did I miss something?

I don't see an easy fix.  See what I said about incremental completion etc., if
you're interested.

>  > Your "because" has nothing to do with the clause it is 
>  > applied to (AFAICT). That the caller of
>  > `with-output-to-temp-buffer' might not know which window
>  > displays the temp buffer is not a reason to make the 
>  > window that is to be scrolled always be the *Completions*
>  > window.  That just doesn't follow.
> 
> Why do you use the term "always" here?  `minibuffer-scroll-window' is
> set to the window used for displaying the temporary buffer 
> which can be *Completions* or *Help* or whatever you have.

Whenever the minibuffer is used for completion, and *Completions* is displayed,
it is automatically set to the *Completions* window.  So not quite always, since
you can use the minibuffer without completion.

>  > I would like to set `minibuffer-scroll-window' to that 
>  > window (whatever it might be, depending on the context).
>  > But when I do that `minibuffer-scroll-window'
>  > keeps getting reset to the *Completions* window 
>  > (presumably because updating the
>  > set of matching completions redisplays *Completions*).
> 
> So define a variable `my-minibuffer-scroll-window' and whenever
> `with-output-to-temp-buffer' steals the window from you reset
> `minibuffer-scroll-window' to `my-minibuffer-scroll-window' in
> `temp-buffer-show-hook'.

If `temp-buffer-show-hook' is the only culprit, then that might be a workaround.
One way or another I will find a solution for myself (the easiest thing is to
just define a new scroll command that respects a new variable).

That doesn't change the fact (IMO) that this behavior represents a bug.

> I don't follow you here.  What would you tell people using your code
> when they complain that you set `minibuffer-scroll-window' to a window
> they don't want to scroll?

Users of my code already scroll *Completions* using different keys (which
invokes different code), anyway.  And they would appreciate being able to scroll
the other windows they interact with during completion.

> The only doc that could be fixed in this respect is that of
> `with-output-to-temp-buffer'.

>  > But that is not at all what the doc indicates.  It 
>  > suggests strongly that `minibuffer-scroll-window' can be
>  > set to control which window gets scrolled.
> 
> It can.  `with-output-to-temp-buffer' makes use of that property.  And
> you can override it in `temp-buffer-show-hook'.

Should be able to set it at any time and have it take effect (not be wiped out
by `with-output-to-temp-buffer'.  Anyway, it's clear we don't agree.  The simple
solution (trivial in this case) is for me to just roll my own and forget about
using `scroll-other-window(-down)' and `minibuffer-scroll-window', since they
are essentially hard-coded during completion.