[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 13:00:55 -0700 |
> 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.
- 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