3

I have used emacs for several years now and wanted to make the leap to daemon mode and using emacsclient. What has prevented me so far is getting ride(closing) of buffers opend via emacsclient. Note that with the examples below the daemon was already started with emacs --daemon

First problem is:

  • open a file via shell with "emacsclient -q -c a.txt"
  • open a b.txt from inside emacsclient via "C-x C-f b.txt"
  • executing "C-x #" in buffer b.txt switches to buffer a.txt, but does not close buffer "b.txt"
  • executing "C-x #" in buffer a.txt closes the client frame and kills buffer a.txt, but buffer b.txt remains open (runnig afterwards "emacsclient -q -c" and checking Ibuffer will show buffer b.txt as available.)
  • I can only get rid of b.txt by going into its buffer and executing "C-x k"

The first question is how can I get rid of b.txt by simply closing the frame which opened it via "C-x C-f".

The second problem is:

  • open a file via shell with "emacsclient -q -c a.txt"
  • open a file via shell with "emacsclient -q b.txt"
  • when being in buffer a.txt, executing "C-x #" closes buffer a.txt AND KILLS the frame, but buffer b.txt remains open (runnig afterwards "emacsclient -q -c" and checking Ibuffer will show buffer b.txt as available.)
  • the same holds when executing "C-x C-c", a.txt is closed, b.txt remains open

  • only when running "C-x #" first in buffer b.txt and then in buffer a.txt will keep the frame open until both buffers are closed

The second question is therefore similar to the first: how can I close all buffers associated to a frame by executing "C-x C-c", and, in case I use "C-x #" how can I keep the frame alive until the last buffer associated to it is close.

Any idea or suggestions.

Thanks a lot.

Cheers

  • 5
    The only buffer associated with an emacsclient frame is the one that you opened with the original call to emacsclient. All other buffers, including the ones you opened after you started emacsclient, are treated the same - just one of the many buffers open in the emacs daemon process. There isn't any built-in way for Emacs to keep track of which buffers were opened from which frames, other than the first one. On the other hand, if you save the buffers you want to keep, it doesn't really matter if they're still 'open' in the emacs daemon? – Tyler Sep 13 '16 at 1:21
1

how can I get rid of b.txt by simply closing the frame which opened it via "C-x C-f".

(defun kill-buffer-plus-frame ()
  "kill the current buffer plus current frame"
  (interactive)
  (kill-buffer)
  (delete-frame))

This function will kill the current buffer and delete the current frame. Keep in mind that the buffer visiting a.txt is actually the buffer associated with that frame, so deleting that frame will also delete the buffer visiting a.txt.

how can I close all buffers associated to a frame

"The only buffer associated with an emacsclient frame is the one that you opened with the original call to emacsclient. All other buffers, including the ones you opened after you started emacsclient, are treated the same." -- @Tyler's comment

If you really want to close all buffers associated to a frame, by deleting the frame, maybe you should not use Emacs as daemon.

  • 1
    +1 "maybe you should not use Emacs as daemon". What OP is asking for is kind of at-odds with the way emacsclient is designed. Probably better to get used to leaving buffers open, or to use regular Emacs to isolate buffers in different frames (and different Emacs processes). – Tyler Sep 14 '16 at 17:32
  • Thanks for the clarification. I love emacs but some stuff is really odd. The big advantage when using the daemon is the start-up time. This advantage vansishes a bit give the above behaviour. – user1407220 Sep 15 '16 at 21:56
  • @user1407220 That is the reason of this community, to help you for the odd stuff :) – Nsukami _ Sep 17 '16 at 18:53

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.