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 21:13:56 -0700

> > Thanks for the info.  But why should that happen?
> 
> Because minibuffer.el wants minibuffer-scroll-window to point to
> *Completions* after popping up a list of completions.

And even if it was already given another window as value, apparently.

> > On the contrary.  This is a variable, created presumably to let you
> > change the window to be scrolled from the minibuffer.  And the doc
> > supports this as the intention.
> 
> No, not to "let you ..." but to "let code ...".

So you are excluding user code.  OK, your intention is clear.

In that case, why document it?  The doc gives a completely different impression
- it suggests that user code can set this variable to determine which window
gets scrolled from the minibuffer by `scroll-other-window'.  (And it can, like
it or not - except during completion.)

And this variable is quite old, certainly much older than the minibuffer.el code
that makes one use of it.  And it was explicitly exposed to users and documented
from the outset (with no exception made for completion).

But hey, who said history doesn't allow revision?  I do however suggest you
change the doc in that case so it fits your intention better.  And what do I
know anyway?  Maybe it never should have been documented; maybe it was always
intended as internal-only.

Anyway, I got the message; I'll just roll my own here, since
`minibuffer-scroll-window' is useless in this context and anyway not intended
for user code.

That's trivial, and I would have done it from the beginning, but it sounded from
the doc like `scroll-other-window' and `minibuffer-scroll-window' were
ready-made to scroll a particular window from the minibuffer.  Even during
completion.  Silly me.

It seems, in any case, that it is only the use of completion that locks code out
from binding/setting the variable usefully.  Other uses of the minibuffer pose
no such limitation.  `widget-choose', for instance, binds the variable on the
fly during minibuffer input, but it does not try to do that during completion.

So if you change your mind and decide it's OK for user code to use this
variable, then you might want to change the doc just a bit to mention that
completion is an exception: *Completions* is always the other window to scroll.






reply via email to

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