[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#8358: 24.0.50; `minibuffer-scroll-window' with active minibuffer: al

From: Drew Adams
Subject: bug#8358: 24.0.50; `minibuffer-scroll-window' with active minibuffer: always *Completions*?
Date: Mon, 28 Mar 2011 09:22:13 -0700

> `minibuffer-scroll-window' is not a user option.  So by design it's a
> variable any code is allowed to change.

Yes, any code, including user code.  And it is explicitly called out in the doc
of `scroll-other-window', to let programmers know about it.  We don't generally
do that for internal variables that are used only to always produce the same
visible behavior.

Yes, I realize that the window object used for *Completions* changes.  But if
that were the only reason for this variable then I doubt that it would figure in
the user documentation.

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

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.

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

It won't do the job needed anyway.  In a single minibuffer input reading I
dynamically update the set of matching completions according to what the user
types (similar to the incremental completion of ido or icomplete, but using

Depending on what the user does (e.g., particular minibuffer keys s?he hits),
the "other" window to be scrolled needs to change.  Think, for example, of a
minibuffer key that displays some information in another window, which the user
might then want to scroll.

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*).

> I'm only trying to explain what happens

I appreciate that; thank you.
> 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.

You mean because *Completions* is in fact the window that gets scrolled? That's
putting the cart a bit before the horse.

As I said, if the intention were only that *Completions* should always be
scrolled, then the doc would say so: in the minibuffer, the *Completions* window
is the other window scrolled.  It could add that the *Completions* window is the
value of `minibuffer-scroll-window' (but it need not even bother).

If that were the intention then the doc for `minibuffer-scroll-window' would
simply say that it is the *Completions* window, which you can scroll from the
minibuffer using C-M-v.  And the variable might as well be named something like
`completions-window' in that case.

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.

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

I guess I'll just forget about `minibuffer-scroll-window' and
`scroll-other-window', and simply roll my own command that scrolls the window
that I tell it too.  If Emacs Dev is not interested in fixing this, so be it.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]