[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: 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 (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 
> of `scroll-other-window', to let programmers know about it.  We don't 
> 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 
> 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 
> might then want to scroll.
> I would like to set `minibuffer-scroll-window' to that window (whatever it 
> be, depending on the context).  But when I do that `minibuffer-scroll-window'
> keeps getting reset to the *Completions* window (presumably because updating 
> 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

>> 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? 
> 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* 
> is the other window scrolled.  It could add that the *Completions* window is 
> value of `minibuffer-scroll-window' (but it need not even bother).

The only doc that could be fixed in this respect is that of

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


reply via email to

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