Last active buffer from old frame should not be added to new frame's perspective while using emacsclient
blahgeek opened this issue · comments
Steps to reproduce
- Run emacs daemon.
- Create first frame (
emacsclient -c), find some buffer(say,init.el) - Create another frame (
emacsclient -c)
Expected behavior
Since the new frame created by emacsclient finds scratch buffer by default, the main perspective of this new frame should only contains this current scratch buffer.
Actual behavior
The main perspective of this new frame includes two buffers: the current scratch buffer, and the last active buffer from the old frame (init.el)
My temporary workaround
(defun my/switch-to-scratch-buffer (f)
(with-selected-frame f
(switch-to-buffer "*scratch*" t)))
(add-hook 'after-make-frame-functions #'my/switch-to-scratch-buffer)
I implemented something similar to your workaround on this branch: https://github.com/nex3/perspective-el/tree/gcv-new-frame-fix
Let me know if that branch works for you.
I implemented something similar to your workaround on this branch: https://github.com/nex3/perspective-el/tree/gcv-new-frame-fix
Let me know if that branch works for you.
Works for me, thank you for your implementation.
One little issue though (which also apply to my own workaround): the first frame that emacsclient opened defaults to open the welcome buffer with the emacs logo instead of scratch buffer, but with this patch, it will always show the scratch buffer. Also, it seems that some people would customize this behavior (e.g. https://github.com/emacs-dashboard/emacs-dashboard), I'm not sure how this patch work with this use case. Personally I'm fine with the scratch buffer.
Good point. I changed my implementation to respect initial-buffer-choice.
Fix now merged into master, should be in MELPA soon.
@gcv I noticed that you committed another change to not kill perspectives when closing frames created by emacsclient. (13fb1dd) Before that commit, this "kill buffers when closing frames" feature works well for me with emacsclient and I've never encountered the bug you have. I cannot reproduce the crash with your described steps in the commit either.
Can we revisit this change? Maybe it's related to some specific emacs version? In that case, maybe can we have an customizable option for it? I'm using 28.0.50 native-comp branch in linux.
Emacs 27.1 with Mac patches, built from source. This used to work fine, but I retested with 26.3 and had the same problem. It’s totally bizarre.
I actually don’t mind reverting the patch, since I don’t use emacsclient with dedicated frames. If this problem doesn’t occur for anyone else.
Looking into this a bit further: the problem only occurs if server-start was called before persp-mode initialized. Otherwise, it works just fine. Let me try to work around it.
Just pushed da3a360.
The procedure in the commit is 100% reproducible on my machine with Emacs 27.1 in a sandbox environment (i.e., with only perspective-el installed and no other configuration loaded).
I found another related issue:
- Open frame A (by default, scratch buffer is opened), open /some/file.txt here
- Open frame B (also, scratch buffer is opened), kill this scratch buffer
Actual behavior: /some/file.txt buffer is added to frame B.
It seems that during the call of switch-to-prev-buffer, set-window-buffer is called which causes the buffer to be added to perspective.
Emacs itself does unexpected things and pulls up hidden buffers like " *Minibuf-0*" when you kill the last normal buffer. In the case of Perspective, the *scratch* buffer is shared between the default main perspectives of different frames, and killing it will impact other frames. prev-buffer is a tough nut to crack for Perspective (see #63). Hacking around this is likely to be error-prone and I'm not sure the effort is justified for such a corner case. (Though I can be convinced otherwise.)
I have an issue which sounds like it might be similar to what is being described in this issue. I use a lot of short-lived emacsclient -c for things such as the Edit with Emacs plugin for Firefox. Often when I close a frame it will cause the current perspective of a different frame to be killed. Additionally, the killed perspective is killed in such a way that it is not removed from the list of perspectives, but attempting to switch to (or re-create) it issues an Using killed perspective <name> error.
I have been running persp version 2.9 on emacs 27 run as --fd-daemon. I will see if your updates up to version 2.11 makes this any better.
@magne-hov: Yes, that’s exactly what I observed. The problem should be worked around in 2.11. That said, you may find the workaround also undesirable, depending on how you use the short-lived frames. If you open other buffers in those frames, they will then become orphaned (i.e., unassociated with any perspective).
If this is a problem, try changing your Emacs setup to start the emacsclient server after persp-mode initializes. Let me know if that fixes all bad behaviors. It’s a mysterious bug, and one I’d really like to squash.