Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Don't close frame when done #172

Open
HarrisonMc555 opened this issue Aug 3, 2020 · 8 comments
Open

Don't close frame when done #172

HarrisonMc555 opened this issue Aug 3, 2020 · 8 comments

Comments

@HarrisonMc555
Copy link

My apologies if this is already documented somewhere and I just didn't find it—I've searched customize for "edit server" and looked through open and closed issues on GitHub and didn't find it.

My personal preference when using the Emacs edit server is to open a new buffer (but not a new frame) when invoked. I would then like to close this buffer (typically with C-c C-c) and close the buffer—but not close the entire frame.

I usually only have one Emacs frame open at a time, so when I invoke the edit server from Chrome it creates a new buffer. I will typically close all other buffers besides the edit server buffer. However, if I do that, then when I finish the edit server buffer and press C-c C-c, it closes the frame and my entire GUI frame is closed. So, I have to launch the GUI again from the command line.

So, my question is this: can I configure edit-server to not close the frame when I'm done with the buffer? But to only close the buffer? When I close other buffers (e.g. kill-current-buffer) the buffer is closed and I'm brought to a different (most recent?) buffer.

For more background information, I am using the Emacs daemon (emacs --daemon) on macOS Mojave. I am using a relatively recent version of emacs_chrome installed manually so I could have access to custom keyboard shortcuts 😄 I believe I installed it about a month or two ago.


And thank you for a great tool! It's really cool and helpful.

@stsquad
Copy link
Owner

stsquad commented Aug 4, 2020

The control of edit-server-done is based on edit-server-new-frame. If it's not set it shouldn't be deleting the frame (but it will delete the window).

@stsquad
Copy link
Owner

stsquad commented Aug 4, 2020

I think I understand what is happening. Because you only have window visible the whole frame disappears because nothing is left. On my emacs if I attempt that the frame survives but I get the message:

"delete-window: Attempt to delete minibuffer or sole ordinary window"

Could you try the following patch and report back:

modified   servers/edit-server.el
@@ -641,7 +641,8 @@ When called interactively, use prefix arg to abort editing."
         ;; don't run abort twice in a row.
         (remove-hook 'kill-buffer-hook 'edit-server-abort*)
    (kill-buffer buffer)
-	(unless edit-server-new-frame
+	(unless (or edit-server-new-frame
+                    (not (window-parent (window-normalize-window nil))))
      (delete-window)))
       (edit-server-kill-client proc))))

It seems a bit ugly but let me know if it works for you first.

@HarrisonMc555
Copy link
Author

That totally works! Thank you. Do you think this is the right approach overall? Is there a reason we're using delete-window instead of kill-buffer? Or what if we used delete-window when edit-server-new-frame is set and kill-buffer when it's not?

@stsquad
Copy link
Owner

stsquad commented Aug 4, 2020

I think the idea of kill-window is it returns your editing layout to where you were before. Of course being emacs I'm sure there are users who can tweak the layout via hooks but I think we want the default case to be as neat as possible. That said I have no idea what the breakdown of users using single-frame vs new-frame semantics is.

@HarrisonMc555
Copy link
Author

Would it be reasonable to add the ability to customize the "quit" function? With a default of delete-window and a recommended alternative of kill-buffer? I could look into making a pull request if that's something we would want to do.

@stsquad
Copy link
Owner

stsquad commented Aug 4, 2020 via email

@HarrisonMc555
Copy link
Author

Ok sounds good! I'll probably look into that later this week.

@billsacks
Copy link

I wanted to chime in to say that I'd also prefer if delete-window was not called.

My use case / configuration is a little different from @HarrisonMc555's: I usually have a frame that is split into two windows. When I have edit-server-new-frame set to nil, the edit server window pops open in one of the windows in my split frame, as desired. However, when I run edit-server-done, the function deletes whichever window the edit server buffer had been in, removing my split. I can recover via winner-undo, so this isn't a huge deal, but it feels to me like the window shouldn't be deleted when you are done editing.

I also want to thank you for putting together this very useful package!

billsacks added a commit to billsacks/.emacs.d that referenced this issue Jun 25, 2021
I was finding the use of a new frame annoying, both because: (1) I'd
prefer to have all of my other open buffers available alongside the
edit-server window, and more importantly (2) with the use of a new
frame, whenever you save, the frame is deleted and recreated; this means
that, if I had split the frame, opened any other buffers in that frame,
etc., all of that work is lost (and winner doesn't seem to be able to
recover it, maybe because that frame is totally gone).

The problem with NOT using a new frame is that when you're done (with
C-c C-c), the current window gets deleted (see also
stsquad/emacs_chrome#172). I'll work around
that by using winner-undo.

I thought about adding this (in misc.el; not yet tested):

(require 'edit-server)
;; This is a total hack to prevent the edit-server from deleting the current window when
;; finishing. Otherwise, when edit-server-new-frame is nil, when finished editing, the
;; edit server's window is deleted, which I don't like. Ideally the edit-server code
;; wouldn't do that, but this function is a hacky workaround to prevent it.
(defun my-edit-server-done ()
  (interactive)
  ;; Here is the total hack: we temporarily set edit-server-new-frame to t to trick
  ;; edit-server-done into not calling delete-window. This works for now because the only
  ;; use of edit-server-new-frame is in a conditional to decide whether to call
  ;; delete-window, but if it were used for anything else, this might break.
  (let ((edit-server-new-frame t))
    (edit-server-done)))

but I'll just add that if winner-undo isn't enough of a fix.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants