all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: "'Stefan Monnier'" <monnier@iro.umontreal.ca>
Cc: 8358@debbugs.gnu.org
Subject: bug#8358: 24.0.50; `minibuffer-scroll-window' with active minibuffer: always	*Completions*?
Date: Mon, 28 Mar 2011 21:13:56 -0700	[thread overview]
Message-ID: <E94BE6F935844FC5BF2C87B5F7034616@us.oracle.com> (raw)
In-Reply-To: <jwvfwq7nv3k.fsf-monnier+emacs@gnu.org>

> > 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	other threads:[~2011-03-29  4:13 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-27 22:03 bug#8358: 24.0.50; `minibuffer-scroll-window' with active minibuffer: always *Completions*? Drew Adams
2011-03-28  6:34 ` martin rudalics
2011-03-28 13:44   ` Drew Adams
2011-03-28 15:01     ` martin rudalics
2011-03-28 16:22       ` Drew Adams
2011-03-28 18:51         ` martin rudalics
2011-03-28 20:00           ` Drew Adams
2011-03-29  1:05             ` Stefan Monnier
2022-02-13  9:58       ` Lars Ingebrigtsen
2011-03-28 15:07     ` Stefan Monnier
2011-03-29  4:13       ` Drew Adams [this message]
2011-03-29  8:54         ` martin rudalics
2011-03-29 14:22           ` Drew Adams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=E94BE6F935844FC5BF2C87B5F7034616@us.oracle.com \
    --to=drew.adams@oracle.com \
    --cc=8358@debbugs.gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.