When I start emacs (emacs
), and then eval (visible-frame-list)
, I get a list with one frame, the one that is visable. However if I start emacs as a daemon (emacs --daemon
), and then eval (visible-frame-list)
(emacsclient --eval '(visible-frame-list)'
). I also have one frame, but as expected this is none visible.
This causes a problem, because after I do emacsclient -c
I get a real frame, and (visible-frame-list)
evaluates to two frames.
Why is this a problem? I have some emacs lisp code that does shuts down emacs when there are no-longer any frames, but it does not trigger because of this out by one error.
(defun intelligent-close ()
"quit a frame the same way no matter what kind of frame you are on"
(interactive)
(if (eq (car (visible-frame-list)) (selected-frame))
;;for parent/master frame...
(if (> (length (visible-frame-list)) 1)
;;close a parent with children present
(delete-frame (selected-frame))
;;close a parent with no children present
(save-buffers-kill-emacs))
;;close a child frame
(delete-frame (selected-frame))))
I could “fix it” by changing the 1
to a 2
, but I suspect that this will cause it to get a false positive at some point in the future.
Can you help to:
- get rid of this extra frame
- be confident that my hack will always work
- OR find another solution
A don't care which.
note If I do
emacs --daemon
emacsclient -c --no-wait
emacsclient --eval '(delete-frame (car (visible-frame-list)))'
emacsclient --eval '(visible-frame-list)'
Then I get the desired result (for this state).
delete-frame
stanza toserver-mode-hook
, but that doesn't get called when you enterserver-mode
via the daemon, which is arguably a bug in emacs. Or you can hack emacs to set the initial frame invisible, but that no doubt also has other effects.