From: Drew Adams <drew.adams@oracle.com>
To: martin rudalics <rudalics@gmx.at>, 28978-done@debbugs.gnu.org
Subject: bug#28978: 26.0; Regression: separate, dedicated `*Completions*' frame no longer has parameter `minibuffer'
Date: Sun, 29 Oct 2017 16:56:49 -0700 (PDT) [thread overview]
Message-ID: <2cb4dbe7-57a6-4a87-9897-224f2d602abe@default> (raw)
In-Reply-To: <59F61A30.30300@gmx.at>
> > And no, there is no problem such as (I think) you
> > describe. In my own setup (but the code is not just
> > for my setup) ALL of the frames except my standalone
> > minibuffer frame have a nil `minibuffer' parameter.
> > And none are mistakenly removed. Only the windows
> > and frames showing BUFFER are affected, and only
> > windows showing BUFFER are removed.
>
> Then I have difficulties to understand what this part of your code tries
> to do:
> (setq mini-param
> (cdr
> (assoc
> 'minibuffer
> (frame-parameters this-frame))))
> (eq mini-param (active-minibuffer-window))
>
> You set mini-param to the 'minibuffer' parameter of this-frame which is
> IIUC your *Completions* frame.
Yes.
> If you say that this parameter is always nil for this-frame,
> why do you retrieve it?
In my setup all frames except the minibuffer frame have no
minibuffer.
The code is not only for my setup. It is Icicles code, so
it must handle any kind of setup.
> If all you want to check is whether this-frame is the active
> minibuffer window's frame, then there should be easier ways
> to do that like, for example,
>
> (and (active-minibuffer-window)
> (eq this-frame (window-frame (active-minibuffer-window))))
Yes, that looks like it corresponds to the check I've
been doing - thanks.
I was checking the `minibuffer' parameter of THIS-FRAME,
to see if it was the `active-minibuffer-window'. But it
should be just as good to check that the frame of the
`active-minibuffer-window' is THIS-FRAME.
I don't think the code you showed earlier corresponds to
the same thing. IIUC, the test you suggested earlier
checks whether the window that was selected immediately
before the current minibuffer window was selected is the
same as the selected window of THIS-FRAME. That's not
the same thing as what I need to test, AFAICT. But your
latest suggestion seems to check what I've been checking,
and it should work OK in all Emacs versions.
> > And even if that is the actual meaning/behavior of
> > that function, the doc string is not appropriate.
> > In that case it is inappropriate because it allows
> > the other meaning: after instead of before. Either
> > way, the doc string is misleading/ambiguous.
>
> Please suggest a better one.
Return the window that was selected immediately
before the current minibuffer window was selected.
One way or another, it should say that the window
returned was selected BEFORE the minibuffer window
was selected. It is not the minibuffer window
(which can easily be understood as "the window
selected when entering the minibuffer").
> > Could you please post the fixed string here, so I
> > can see it? Clearly I don't understand this yet.
> > Hopefully that will help. Thx.
>
> The doc-string is probably not much better:
>
> Return the window which was selected when entering the minibuffer.
> Return nil if the selected window is not a minibuffer window.
Right - not better. Same problem as before: "when
entering" is ambiguous.
Some window is the selected window before entering, and
some window is the selected window after entering. But
"when entering" means little - whether it is regard as
an instant or a time period, either way it's unclear
which window is meant - before or after the minibuffer
window becomes the selected window.
Plus there is the ambiguity of "the minibuffer" when
talking about minibuffer windows, since there can be
multiple minibuffer windows. And a minibuffer window
could be selected before another minibuffer window
gets selected. "When entering the minibuffer" tells
you nothing about which of those minibuffer windows
is the `minibuffer-selected-window'.
> The Elisp documentation now has
>
> This function returns the window that was selected
> at the moment
^^^^^^^^^^^^^
> the minibuffer was entered. If the currently selected
> window isnot a minibuffer window, it returns `nil'.
>
> which you might want to improve as well.
Same problem; same solution - see above. At the moment
the change is made, which window is the selected window?
My suggestion is to say that it is the window that
was selected JUST BEFORE the minibuffer was entered.
Thanks.
next prev parent reply other threads:[~2017-10-29 23:56 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 [this message]
2017-10-30 8:24 ` martin rudalics
2017-10-30 14:32 ` Drew Adams
2017-10-30 19:00 ` martin rudalics
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2cb4dbe7-57a6-4a87-9897-224f2d602abe@default \
--to=drew.adams@oracle.com \
--cc=28978-done@debbugs.gnu.org \
--cc=rudalics@gmx.at \
/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.