[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
*Completions*).
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.
- bug#8358: 24.0.50; `minibuffer-scroll-window' with active minibuffer: always *Completions*?, Drew Adams, 2011/03/27
- bug#8358: 24.0.50; `minibuffer-scroll-window' with active minibuffer: always *Completions*?, Stefan Monnier, 2011/03/28
- bug#8358: 24.0.50; `minibuffer-scroll-window' with active minibuffer: always *Completions*?, Drew Adams, 2011/03/29
- bug#8358: 24.0.50; `minibuffer-scroll-window' with active minibuffer: always *Completions*?, martin rudalics, 2011/03/29
- bug#8358: 24.0.50; `minibuffer-scroll-window' with active minibuffer: always *Completions*?, Drew Adams, 2011/03/29