Close frame in persistent-server mode not working correctly

[moesasji]

On 0.103.5 the option SPC q z to close frames connected is not working correctly as it doesn't return after closing the frame. To reproduce:

1. Start Emacs with dotspacemacs-persistent-server t set in the config file.
2. From a terminal window type "emacsclient -c"
3. Exit from the open emacs frame that opens with SPC q z
4. The Emacs frame disappears, but the terminal remains at "Waiting for Emacs..." until I hit CTRL C as the emacsclient process doesn't terminate as instructed.

*) Note that the suggested emacs keybinding in the minibuffer C-x 5 0 does correctly close the frame and exit from the terminal.

btw) A sideline as it might be a feature. I find it annoying/confusing that hitting SPC q q in a frame is closing all emacs windows when there are no unsaved changes as this is way to easy to do by accident. I would find if more logical that the easy to hit key-binding SPC q q would close the frame when dotspacemacs-persistent-server is t (if it is nil then close emacs as expected). Closing all windows including the server could then for example be on SPC q a (quit all) or the SPC q z now closing the frame.

[StreakyCobra]

I tried to reproduce this on the develop version, but the emacsclient is quitting directly after SPC q z and the terminal is not waiting on Wainting for Emacs..., it prompts for a new command. Do you still have the problem on your side?

[moesasji]

1. The issue with the prompt not returning is indeed fixed in 104.4. (I'm not running develop)

2. The other comment that 'SPC q q' kills ALL emacs frames in case there are no unsaved changes is still the case. This I find extremely annoying behavior as it is too easy to hit this by mistake, because this is the key-binding used to close the frame/window without a persistent server running.

[StreakyCobra]

1. 👍
2. I agree with you but not everyone does. Let's label this discussion then, I'll start the debate on gitter. If it's a no-go, then I'll add an explanation in the FAQ how to change this as an user-configuration 😄

[StreakyCobra]

I propose to change the following:

In "normal" mode:

• SPC q z acting as bb/maybe-quit (show below)

In "daemon" mode:

• SPC q z acting as bb/maybe-quit (idem as in normal mode)
• SPC q q acting as spacemacs/frame-killer
• SPC q Q acting as spacemacs/prompt-kill-emacs

The reason why bb/maybe-quit function is better than just frame-killer is because when not in daemon mode, killing the last frame should also kill emacs, otherwise it will stay running in background.

---

(defun bb/maybe-quit ()
           (interactive)
           (if (cdr (visible-frame-list))
               (call-interactively 'spacemacs/frame-killer)
             (call-interactively 'spacemacs/prompt-kill-emacs)))

[calebmeyer]

I agree with this proposal. It's very annoying to have to restart emacs daemon every time I SPC q q.

[andrew-kennedy]

@StreakyCobra this proposed behavior seems to not yet be implemented, is it as simple as remapping the stock spacemacs keybindings and remapping the SPC q z keybinding to support the bb/maybe-quit function? I'd be willing to tackle it if so.

EDIT: from what I've gathered from digging through the code a bit, what also needs to be implemented is a function to determine whether emacs is running in daemon mode?

[jballanc]

While this may not be the most common use case, I've found that this issue is not completely fixed once you throw emacsclient -n -c into the mix. To reproduce:

• Start emacs daemon - emacs --daemon
• Edit a file using a new frame, returning immediately (on OS X when compiled --with-cocoa, this opens the file in a new native window) - emacsclient -n -c ~/.zshrc
• Now edit a different file using the existing frame - emacsclient ~/.zshenv

From here, if you use SPC q z to invoke the frame killer, the new frame is killed but emacsclient doesn't return, leaving the terminal at Waiting for Emacs.... Additionally, using the frame killer in this instance isn't exactly what I want, since I'd rather just have the second buffer opened (the one with ~/.zshenv) closed but leave the frame with the first buffer (~/.zshrc) still open.

As it happens, using the Emacs suggested C-x # method of closing the second buffer (invoking server-edit) does exactly what I would want in this situation: closes the ~/.zshenv buffer, returns from the second emacsclient invocation, and leaving behind the native window with ~/.zshrc still open.

In fact, server-edit does exactly what I want when using an Emacs server in all circumstances (not just the slightly contrived example above). So I would advocate for simply adding a key-binding for this function.

Unfortunately, all the most obvious mnemonics (SPC q d for "done" or SPC q s for "server-edit") are already taken.

[punassuming]

All, I made some changes to persistent-server in #8019, you want to see if that helps with the issues? It fixes the logic (which was broken for frame killing) and it allows you to close the server even when debug is active.

[et2010]

The other comment that 'SPC q q' kills ALL emacs frames in case there are no unsaved changes is still the case.

Any updates on this?

I'm on develop branch and this comment is still true, even with dotspacemacs-persistent-server set to t.

[davidpiano]

In my opinion, there are a number of possibilities for "correct" behaviour of key bindings for closing/suspending/quitting, depending partly on how Emacs is being run - a single terminal emulator, multiplexed terminals on tmux or similar, a graphical environment, local, remote, different OS, and so on - and partly on the preferences and habits of individuals.

I think it might make sense therefore (if possible) for Spacemacs to expose more of those possibilities by adding new bindings rather than trying to choose just one or two.

About the persistent server, I really just wish it worked in a predictable way, with my own preference being to make it easy to activate and hard to kill... based on the idea that having to force kill an unwanted process is merely inconvenient, but accidentally killing a process could lose my work.

[diego898]

Just want to ping this issue

[safijari]

I recently started using daemon mode and this brought my enthusiasm for it to a screeching halt. Is there any workaround? I have the dotspacemacs-persistent-server variable set to true.

[rationalis]

SPC q f and SPC F d both serve the purpose of closing a frame without killing the server, so I think this is working as intended? If SPC q q killing the server still bothers you I guess you could rebind SPC q q to frame-killer as well (same as SPC q f) and SPC q Q to prompt-kill-emacs (the original default behavior of SPC q q).

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please let us know if this issue is still valid!