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

[martin rudalics]

>> `with-output-to-temp-buffer' which displays the *Completions* buffer
>> sets `minibuffer-scroll-window' to the window showing *Completions*.
>
> Thanks for the info.  But why should that happen?  
`with-output-to-temp-buffer'
> is supposed to be general, for any temporary buffer.  It is not supposed to be
> specific to *Completions* or *Help* or any other given temporary buffer.
>
> And the doc of `scroll-other-window' says that "`minibuffer-scroll-window' if
> non-nil specifies the window to scroll."  It doesn't say that it always
> specifies the *Completions* window.
>
> And the doc of `minibuffer-scroll-window' says "Non-nil means it is the window
> that C-M-v in minibuffer should scroll."  It doesn't say that C-M-v in the
> minibuffer always scrolls *Completions*.
>
> There is nothing to indicate that things are in fact hard-coded so that the
> window to scroll when you are in the minibuffer is always *Completions*.  And
> there is nothing to indicate that that is the intention (design).
>
> On the contrary.  This is a variable, created presumably to let you change the
> window to be scrolled from the minibuffer.  And the doc supports this as the
> intention.

`minibuffer-scroll-window' is not a user option.  So by design it's a
variable any code is allowed to change.  I suppose that it's set in
`with-output-to-temp-buffer' because that macro is quite opaque so the
caller isn't even informed about which window displays the buffer.

>> Try doing
>> (add-hook 'temp-buffer-show-hook 'foo 'append)
>> instead.  Or write your own `temp-buffer-show-function'.
>
> Thanks, but such a workaround is a sledge hammer here.  
`temp-buffer-show-hook'
> is general, and it should not be necessary to add and remove stuff just to get
> `minibuffer-scroll-window' to act as a variable.
>
> I appreciate the implementation info, but this seems like a bug to me.

`temp-buffer-show-hook' is provided to override the built-in behavior of
`with-output-to-temp-buffer'.  If I were annoyed by the behavior I would
use it to fix such problems.

> `minibuffer-scroll-window' is used only when the minibuffer is active, and it 
is
> apparently always set, in that case, to the *Completions* window.  This was
> created as a variable presumably so that programs could change the window to 
be
> scrolled from the minibuffer.

Yes.

> It's not clear whether you are just explaining what currently happens (thank
> you) or you are also saying that this is not a bug.  What's the point of
> `minibuffer-scroll-window' if it is always effectively *Completions*?

I'm only trying to explain what happens, I don't use C-M-v myself.  But
I suppose that if you removed the corresponding assignment from
`with-output-to-temp-buffer', the completions coder would add a similar
assignment to `temp-buffer-show-hook'.

> Other than this hard-coded case, user code has easy control over
> `scroll-other-window(-down)'.  Can we please fix this so that
> `minibuffer-scroll-window' acts as advertised?

The doc-string of `minibuffer-scroll-window' says

  Non-nil means it is the window that C-M-v in minibuffer should scroll.

so IIUC it acts as advertised.  If the window has been deleted in the
meantime, it's slightly out of synch but this problem is handled by
`other-window-for-scrolling'.  But you probably should try to find out
why it has been designed this way and/or propose an appropriate fix for
the completions code.

martin