I recently updated to emacs 28.2. Prior to this if I hit C-x v l (vc-print-log) to see a file's git history, the window split horizontally. I'd have the file on one side and the commit history in what basically appeared as another column.

With the upgrade to 28.2 (I believe), when I do this, the window splits vertically.

My frame size is the same as it was before. No other changes to my start up files.

Update, per comment: Current window: 204 columns x 68 lines split-width-threshold: 160 split-height-threshold: 80

  • Check the values of split-width-threshold and split-height-threshold and add them (as well as the dimensions of your frame) to your question. See the doc string of split-window-sensibly for some things to try.
    – NickD
    Sep 24 at 2:09

1 Answer 1


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

 '("[*]*vc-change-log[*]" display-buffer-to-the-right


  • 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


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, ....

  1. Check the behaviour with emacs -Q
  2. 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*"))
  1. 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.

  2. 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.

  3. 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 windowdisplay-buffer just used “some” window.

  4. 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.

  • Wow, lots of content there... I'll have a look and report back. Thanks Sep 24 at 14:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.