[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Stop frames stealing eachothers' minibuffers!
From: |
Alan Mackenzie |
Subject: |
Re: Stop frames stealing eachothers' minibuffers! |
Date: |
Sat, 20 Mar 2021 10:28:26 +0000 |
Hello, Eli.
On Fri, Mar 19, 2021 at 17:59:45 +0200, Eli Zaretskii wrote:
> > 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?
The actual moving of the minibuffers isn't the problem ....
> > > > 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.
This initial frame gets used as a normal frame when one calls
$ emacsclient foo
for the first time. It stays in use until one clicks on its close
button (I think this is actually the close button of the containing
xterm). When a new GUI frame is brought up by
M-: (run-at-time 10 nil #'make-frame '((window-system . x)))
, the initial frame may or may not have been "closed" by clicking its
close button. I think you're telling me that it's not possible to
distinguish these two cases. If so, that's surely a defect in Emacs.
> > 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.
Perhaps we should create some means of knowing this? Maybe in
handle-delete-frame, where Emacs has determined there is only one frame
left, before calling save-buffers-kill-emacs we could mark the last
frame's f->visible to "not visible". Or maybe set up a special non-zero
dummy value for f->terminal. Or something like that.
> > 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.
OK. I'm not sure I agree, but it's not really a big point.
--
Alan Mackenzie (Nuremberg, Germany).
- Re: Stop frames stealing eachothers' minibuffers!, (continued)
- 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, 2021/03/19
- Re: Stop frames stealing eachothers' minibuffers!,
Alan Mackenzie <=
- 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
- Re: Stop frames stealing eachothers' minibuffers!, Eli Zaretskii, 2021/03/21