0

When visiting a folder with emacsclient, for example through emacsclient ., using dired, opening a folder using a will cause emacsclient to terminate. I believe this is because a, bound to dired-find-alternate-file will close the buffer emacsclient is in some way bound to causing it to terminate. I observe the same behavior when using dired-single.el.

Is there any way to prevent this from happening? Given my above assumptions about how why this happens: to make dired reuse the same buffer rather than destroy it?

  • dired-find-alternate-file's doc string says: In Dired, visit file or directory on current line via ‘find-alternate-file’. This kills the Dired buffer, then visits the current line’s file or directory. So it seems to me that the only way to avoid the problem is to avoid using dired-find-alternate-file. What's wrong with dired-find-file (bound to f)? It leaves the directory buffer alone, so emacsclient can continue enjoying its existence. – NickD Jul 9 at 8:18
  • I would prefer to not fill upp my buffer list with a lot of dired buffers I will never use again. – Rovanion Jul 9 at 8:21
1

You could remap dired-find-alternate-file to a custom command which firstly checks to see whether server-buffer-clients is non-nil in that dired buffer. If it's nil then just go ahead and call dired-find-alternate-file; if it's set, then work around the issue...

Some possible workarounds are:

  1. Call dired-find-file instead of dired-find-alternate-file. Maybe bury-buffer for the original buffer, too.

  2. Set the buffer-local server-buffer-clients to nil. This will prevent server-kill-buffer from killing every client for which this was the sole remaining buffer of interest. It means there will be a stale entry in the buffers list for the client process -- but server-buffer-done already copes with dead buffers, so it's basically fine.

    Or similar: remove the buffer-local kill-buffer-hook entry server-kill-buffer in that buffer.

    Either way, when the dired buffer is killed, the client stays alive.

    That sounds good, but probably isn't actually sufficient. In the case you're interested in -- the one where that client in reality has no live buffers of interest after that dired buffer has been killed -- then that client is going to be killed the next time that any client-buffer (for any client) is killed -- so you might still lose the client without meaning to.

  3. That all being the case, I think instead of using (2), your custom command would be better to call server-visit-files for the file you're asking dired to open, in order that the new buffer can be registered for the client (in practice you probably need to do this for every client which was interested in the original buffer). Then you're effectively shifting the client's interest from buffer to buffer, but it's not subject to sudden death on account of some other client.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.