[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Stop frames stealing eachothers' minibuffers!
From: |
Eli Zaretskii |
Subject: |
Re: Stop frames stealing eachothers' minibuffers! |
Date: |
Fri, 19 Mar 2021 17:59:45 +0200 |
> Date: Fri, 19 Mar 2021 15:35:13 +0000
> Cc: rudalics@gmx.at, monnier@iro.umontreal.ca, jakanakaevangeli@chiru.no,
> emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
>
> > > , the new frame comes up _with_ the minibuffer visible. I don't
> > > understand how the mini window survived with its contents, and it
> > > worries me.
>
> > Why does it worry you? You've asked Emacs to create a frame, and a
> > frame by default has a mini-window. Right?
>
> I understand it a lot better now. The new mini-window gets the
> minibuffers only because I had minibuffer-follows-selected-frame set to
> t. With either of the other values, the minibuffers remain on the old
> inaccessible frame. This is not good.
Can't you move them from those inaccessible frames to this one?
> > > Could it be that the last frame isn't actually deleted from the Emacs
> > > daemon when clicking on its close button?
>
> > I think indeed that's what happens, because otherwise clicking there
> > would have shut down Emacs -- which it doesn't in the daemon case.
>
> Yes, this is the case. I would dearly like to find a way of determining
> if this last frame is still visible, or iconified, or whatever, as
> opposed to inaccessible.
I think this is the initial frame that exists in every Emacs session
when it starts, except that in the daemon we don't delete it. It's a
non-GUI frame which exists just to keep code that expects some frame
to exist happy.
> The old frame in the above recipe was a -nw frame, effectively a
> TTY, and `frame-visible-p' returns t for it, even though it is not
> even displayable (it's containing shell has gone).
We don't have a means of knowing whether a TTY frame is displayed, it
conceptually always is.
> Hmm. There is effectively nothing about the effect of Emacs as a daemon
> in Elisp.
There's nothing special about that, just some implementation details.
- Re: Stop frames stealing eachothers' minibuffers!, (continued)
- Re: Stop frames stealing eachothers' minibuffers!, Eli Zaretskii, 2021/03/17
- Re: Stop frames stealing eachothers' minibuffers!, Eli Zaretskii, 2021/03/17
- Re: Stop frames stealing eachothers' minibuffers!, Alan Mackenzie, 2021/03/18
- Re: Stop frames stealing eachothers' minibuffers!, Eli Zaretskii, 2021/03/18
- Re: Stop frames stealing eachothers' minibuffers!, martin rudalics, 2021/03/18
- Re: Stop frames stealing eachothers' minibuffers!, Alan Mackenzie, 2021/03/18
- Re: Stop frames stealing eachothers' minibuffers!, Eli Zaretskii, 2021/03/18
- Re: Stop frames stealing eachothers' minibuffers!, Alan Mackenzie, 2021/03/19
- Re: Stop frames stealing eachothers' minibuffers!, Eli Zaretskii, 2021/03/19
- Re: Stop frames stealing eachothers' minibuffers!, Alan Mackenzie, 2021/03/19
- Re: Stop frames stealing eachothers' minibuffers!,
Eli Zaretskii <=
- Re: Stop frames stealing eachothers' minibuffers!, Alan Mackenzie, 2021/03/20
- Re: Stop frames stealing eachothers' minibuffers!, Eli Zaretskii, 2021/03/20
- Re: Stop frames stealing eachothers' minibuffers!, Alan Mackenzie, 2021/03/20
- Re: Stop frames stealing eachothers' minibuffers!, Miha Rihtaršič, 2021/03/20
- Re: Stop frames stealing eachothers' minibuffers!, Stefan Monnier, 2021/03/20
- Re: Stop frames stealing eachothers' minibuffers!, Alan Mackenzie, 2021/03/21
- Re: Stop frames stealing eachothers' minibuffers!, Eli Zaretskii, 2021/03/21
- Re: Stop frames stealing eachothers' minibuffers!, Eli Zaretskii, 2021/03/21
- Re: Stop frames stealing eachothers' minibuffers!, Alan Mackenzie, 2021/03/21
- Re: Stop frames stealing eachothers' minibuffers!, Stefan Monnier, 2021/03/21