From af37d430fb9c0e6571bfea9db3ef77679124b5e8 Mon Sep 17 00:00:00 2001 From: Henrik Lissner Date: Mon, 8 Jan 2018 19:28:50 -0500 Subject: [PATCH] Fix kill-this-buffer's dashboard addiction Our kill-this-buffer advice, which tries to ensure the user will always land on a real buffer after killing another, would prematurely jump to the dashboard even though there were other available, real buffers. Also fixes an issue where kill-this-buffer would get stuck switching between the last buffers (because they aren't killed if they're visible in other windows). If the only buffers left are visible in other windows, it will now switch to the fallback buffer (dashboard or scratch). --- core/core-ui.el | 17 +++++++---------- 1 file changed, 7 insertions(+), 10 deletions(-) diff --git a/core/core-ui.el b/core/core-ui.el index dafb94739..163f931c9 100644 --- a/core/core-ui.el +++ b/core/core-ui.el @@ -531,17 +531,14 @@ instead)." (let ((buf (current-buffer))) (cond ((window-dedicated-p) (delete-window)) - ((eq buf (doom-fallback-buffer)) - (bury-buffer)) + ((or (eq buf (doom-fallback-buffer)) + (doom-real-buffer-p buf)) + (doom--cycle-real-buffers -1) + (kill-buffer buf) + (when (cdr (get-buffer-window-list (current-buffer) nil t)) + (doom--cycle-real-buffers nil))) (t - (let ((real-p (doom-real-buffer-p buf))) - (funcall orig-fn) - (cond ((eq buf (current-buffer)) - (doom--cycle-real-buffers nil)) - ((and real-p (not (doom-real-buffer-p))) - (doom--cycle-real-buffers -1)) - (t - (message "Nowhere to go!")))))))) + (funcall orig-fn))))) (defun doom|init-ui ()