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

[martin rudalics <rudalics@gmx.at>]

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