[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: |
martin rudalics |
Subject: |
bug#8358: 24.0.50; `minibuffer-scroll-window' with active minibuffer: always *Completions*? |
Date: |
Mon, 28 Mar 2011 20:51:16 +0200 |
User-agent: |
Thunderbird 2.0.0.21 (Windows/20090302) |
>> `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.
I still don't understand why you can't or don't want to change it in
your code. Or did I miss something?
> 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.
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.
>> `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.
It will do the job for this particular case.
> 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*).
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'.
>> 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.
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?
> 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).
The only doc that could be fixed in this respect is that of
`with-output-to-temp-buffer'.
> 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 every window used by `with-output-to-temp-buffer' is affected, not
only the *Completions* window.
> 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'.
martin
- 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