#StackBounty: #frames #emacs-daemon extra frame in (visible-frame-list) when started in daemon mode, is causing problems

Bounty: 50

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


Get this bounty!!!

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.