From: martin rudalics <rudalics@gmx.at>
To: Drew Adams <drew.adams@oracle.com>, 28978-done@debbugs.gnu.org
Subject: bug#28978: 26.0; Regression: separate, dedicated `*Completions*' frame no longer has parameter `minibuffer'
Date: Mon, 30 Oct 2017 20:00:08 +0100 [thread overview]
Message-ID: <59F776B8.3070301@gmx.at> (raw)
In-Reply-To: <07ad0bf0-ecf4-4c0c-97c5-665e1ec77312@default>
> Before your change, a separate *Completions* frame didn't
> have a minibuffer-window value for its frame parameter
> `minibuffer' - it used another frame's minibuffer. Before
> your change checking that parameter was a reasonable way
> to check whether the frame had an active minibuffer window.
Your check does not do that. It tries to check whether this-frame has
no minibuffer window and no minibuffer window is active. Given the
Emacs 25 manual which says about the 'minibuffer' parameter
Whether this frame has its own minibuffer. The value `t' means
yes, `nil' means no, `only' means this frame is just a minibuffer.
If the value is a minibuffer window (in some other frame), the
frame uses that minibuffer.
your check was not reasonable. A reasonable equivalent check working
for Emacs 25 and Emacs 26 could be
(and (not (memq (frame-parameter this-frame 'minibuffer) '(t only)))
(not (active-minibuffer-window)))
> Return window selected just before minibuffer window was selected.
I used this.
> I don't think "currently active minibuffer window" is
> the same thing as currently selected minibuffer window.
>
> For one thing, a window is not "active". (Nor is it
> "current", you will say, and that's right.) You probably
> meant "window of the active minibuffer".
I tried to change the documentation in that sense.
> For another thing, if a minibuffer window is selected
> does that necessarily mean that the minibuffer is active?
> I don't think so, but I'm not an expert in this stuff.
You can always switch to a minibuffer window without making its buffer
active.
> Thanks for fixing this.
Thanks for the suggestions, martin
next prev parent reply other threads:[~2017-10-30 19:00 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-24 20:20 bug#28978: 26.0; Regression: separate, dedicated `*Completions*' frame no longer has parameter `minibuffer' Drew Adams
2017-10-25 7:45 ` martin rudalics
2017-10-25 14:47 ` Drew Adams
2017-10-26 7:57 ` martin rudalics
2017-10-26 14:01 ` Drew Adams
2017-10-27 8:25 ` martin rudalics
2017-10-27 14:19 ` Drew Adams
2017-10-28 8:45 ` martin rudalics
2017-10-28 19:15 ` Drew Adams
2017-10-29 11:18 ` martin rudalics
2017-10-29 15:59 ` Drew Adams
2017-10-29 18:13 ` martin rudalics
2017-10-29 23:56 ` Drew Adams
2017-10-30 8:24 ` martin rudalics
2017-10-30 14:32 ` Drew Adams
2017-10-30 19:00 ` martin rudalics [this message]
2017-10-30 19:16 ` 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=59F776B8.3070301@gmx.at \
--to=rudalics@gmx.at \
--cc=28978-done@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).