From: martin rudalics <rudalics@gmx.at>
To: Drew Adams <drew.adams@oracle.com>
Cc: 8358@debbugs.gnu.org
Subject: bug#8358: 24.0.50; `minibuffer-scroll-window' with active minibuffer: always *Completions*?
Date: Mon, 28 Mar 2011 20:51:16 +0200 [thread overview]
Message-ID: <4D90D8A4.6020900@gmx.at> (raw)
In-Reply-To: <FC750131F04E4CC4AD2DDB6EE2F76CDA@us.oracle.com>
>> `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
next prev parent reply other threads:[~2011-03-28 18:51 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 [this message]
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
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D90D8A4.6020900@gmx.at \
--to=rudalics@gmx.at \
--cc=8358@debbugs.gnu.org \
--cc=drew.adams@oracle.com \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).