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).
This commit is contained in:
Henrik Lissner 2018-01-08 19:28:50 -05:00
parent 865fe29a9d
commit af37d430fb
No known key found for this signature in database
GPG Key ID: 5F6C0EA160557395

View File

@ -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 ()