Quick, easy to understand and surely a dumb suggestion ....
FWIW, I am running emacs 29.0.50 (from git repo)
with a -Q
argument, and I have the file which has a huge history in the top, the *vc-change_log*
buffer shows up below the file.
Once I install the following snippet, then *vc-change-log*
shows up to the right.
(defun display-buffer-to-the-right (buffer alist)
(display-buffer-in-direction buffer (cons '(direction . right) alist)))
(add-to-list
'display-buffer-alist
'("[*]*vc-change-log[*]" display-buffer-to-the-right
(nil)))
TLDR:
- Have you ascertained the "default" behaviour with
emacs -Q
?
- Before you invoke the above comand, how are you windows arranged, and what are their properties?
- *Is it possible that the way you had visited the window influenced where the log buffer appeared
TLDRLTDR:
There could be lots of things going on your side---right from the which emacs
you are using (and the customizations these make and you make) to the specific grid structure of your layout to specific usage pattern in current session---and it is difficult to help you unless your provide all that information
vc-log-internal-common
calls pop-to-buffer
with no explicit action
There is also a vc-log-finish-functions
which runs vc-shrink-buffer-window
A quick M-s o
for split
in vc.el
doesn't turn up anything.
So, Emacs
is doing whatever pop-to-buffer
has always done. (You can do M-x find-library vc.el
and take a cursory M-s o
look at that file (or around the places I have linked to) see if older and newer Emacs are doing things differently.
So, ....
- Check the behaviour with
emacs -Q
- If Emacs behaviour hasn't changed, hunt down entries in
display-buffer-alist
or take up the issue with doomemacs
or spacemacs
forums. Or look at the doc string of display-buffer
, and roll out your own custom behaviour.
It is worth looking at all the nodes in Displaying Buffers (GNU Emacs Lisp Reference Manual),specifically the following nodes The Zen of Buffer Display (GNU Emacs Lisp Reference Manual)
A cursory and quick reading of those nodes suggests that the choice of window is determined solely by the geometry of the current grid (and the geomoetry of the propective window), but also the specific usage pattern---the LRU
-ness---of the windows you have traversed. The Precedence of Action Functions (GNU Emacs Lisp Reference Manual) has an example on how the LRU
-ness determines if a buffer shows up on top at the bottom. That is, a window may appear on top or bottom, depending on how recently you have "visited" the windows.
The paragraphs below is an extract from the above node, and thus I am quoting. (Note that the points 3 and 4 illustrate how the LRU
-ness
of the window determines where the window appears.)
(First few paragraphs of Precedence of Action Functions (GNU Emacs Lisp Reference Manual))
Consider the following form:
(display-buffer (get-buffer-create "*foo*"))
Evaluating this form in the buffer *scratch*
of an uncustomized Emacs session will usually fail to reuse a window that shows *foo*
already,
but succeed in popping up a new window.
Evaluating the same form again will now not cause any visible changes—display-buffer
reused the window already showing *foo*
because that action was applicable and had the highest precedence among all applicable actions.
Popping up a new window will fail if there is not enough space on the selected frame. In an uncustomized Emacs it typically fails when
there are already two windows on a frame.
For example, if you now type C-x 1
followed by C-x 2
and evaluate the form once more, foo
should show up in the lower window—display-buffer
just used “some” window.
If, before typing C-x 2
you had typed C-x o
, foo
would have been shown in the upper window because “some” window stands for the “least recently used” window and the selected window has been least recently used if and only if it is alone on its frame.
Demystifying Emacs’s Window Manager provides a more accessible way to approach how buffers are displayed.
split-width-threshold
andsplit-height-threshold
and add them (as well as the dimensions of your frame) to your question. See the doc string ofsplit-window-sensibly
for some things to try.