unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
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: Mon, 30 Oct 2017 07:32:59 -0700 (PDT)	[thread overview]
Message-ID: <07ad0bf0-ecf4-4c0c-97c5-665e1ec77312@default> (raw)
In-Reply-To: <59F6E1C9.5030702@gmx.at>

>  > 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.
> 
> If you told me with plain words what you really wanted to check then I
> might come up with another suggestion.  But "checking the `minibuffer'
> parameter of THIS-FRAME, to see if it was the
> `active-minibuffer-window'" could not have possibly done anything
> reasonable even before my changes.  That test simply failed/succeeded
> accidentally with Emacs 25 and just produces the opposite result with
> Emacs 26.

It not only could possibly have done something reasonable
before your changes, it did something reasonable, useful,
and necessary before your changes.  And as I said: in ALL
Emacs releases.

I think the alternative code you proposed will likely work
as well (thank you), but there is no reason to claim that
the previous code did not work or did nothing reasonable.

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.

>  > Return the window that was selected immediately
>  > before the current minibuffer window was selected.
> 
> Looks good but I need a first line that fits into 67 characters.  Pretty
> please suggest a suitable first line and whatever you consider important
> for the rest.  Also, since we nowhere specify "the current minibuffer
> window" wouldn't "the currently active minibuffer window" be better?

 Return window selected just before minibuffer window was selected.

or even

 Return window selected just before minibuffer window.

Or if this is about an _active_ minibuffer then perhaps:

 Return window selected just before window of active minibuffer.

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".

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.

Thanks for fixing this.





  reply	other threads:[~2017-10-30 14:32 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 [this message]
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

  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=07ad0bf0-ecf4-4c0c-97c5-665e1ec77312@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 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).