bug-gnu-emacs
[Top][All Lists]
Advanced

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






reply via email to

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