cycle-real-buffers was a tidbit of complexity that was never necessary
in the first place. This functionality was already available in the form
of the frame buffer-predicate parameter, which controls where functions
like next-buffer and other-buffer can land you.
The only thing I have to do myself, is check for the condition where
there are no more real buffers left to switch to, and in that case send
you to the fallback-buffer.
doom/{next,previous}-buffer was implemented so that these commands could
skip over unreal buffers, and land us on either a real one or the
dashboard. Using the frame's buffer-predicate parameter accomplishes
exactly this, natively.
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).
Phases out dependence on the doom-kill-buffer workflow, which ensured
the user would always land on a real buffer (or the fallback buffer)
after killing a buffer. This required all quit-window, kill-this-buffer
and various buffer-killing commands be advised or remapped. There was no
need, kill-buffer-query-functions is better.
Also introduces a new hook: doom-init-theme-hook. doom-init-ui-hook
still exists, but is used for UI initialization (surprise), while theme
hooks should be moved over.
The "current" window is forgotten by the time
doom|protect-visible-buffers runs, so use get-buffer-window (native
C function) to detect if another window housing this buffer exists.
Protecting buffers that were visible in other windows (burying them
instead) is not the responsibility of doom-kill-buffer. This is a job
for kill-buffer-query-functions, hence doom|protect-visible-buffers.
