With increasing frequency, my Emacs session's function other-buffer begins to malfunction.

Specifically, at some point, and for no reason I can discern, other-buffer stops "seeing" some random buffer. By this I mean that, for example, even when some buffer xyz was in fact the last buffer I visited before the current one, and shows up in the second row of the *Buffer List* window, other-buffer will not evaluate to xyz, but instead will evaluate to the buffer shown in the third row of the *Buffer List* window1,2.

Unfortunately, other-buffer is not a Lisp function, so I don't know how to go about inspecting its source code. (Actually, even if I had access to its C source, I doubt I would be able to make much sense of it.)

Therefore, I'm looking for any information that may help troubleshoot this problem. As I said, it has been happening a lot lately, so I would like to get to the bottom of it.

What could explain this weird behavior from other-buffer?

1 The other-buffer function is used by switch-to-buffer, better known as "good ol' C-x b", to determine its default argument. When one is flipping back and forth between two buffers, which is an extremely common situation, it is great to be able to rely on this default value, since it always resolves to precisely the buffer one wants to visit. When other-buffer lands in the broken state I described above, and at least one of the buffers one is toggling over is among those that other-buffer has decided to ignore, C-x b becomes cumbersome at best, since one can no longer just hit Enter to accept the default, and supremely infuriating at worst, since the habit of doing precisely this (i.e. hitting Enter to accept the default) is a deeply ingrained one, and as a result one keeps visiting buffers one does not want to visit.

2 Yes, one can solve the problem in the short term by killing the buffer and recreating it. This is always disruptive, and in some cases extremely so. For example, I rely on many buffers (e.g. subordinate shell buffers, debugger buffers, etc.) whose histories are important, and would get discarded by such a re-creation.

  • You should provide a minimum reproducible example (concrete example instead of abstract description).
    – shynur
    Oct 6, 2023 at 13:45
  • 1
    @shynur: I cannot reproduce this situation. It just happens sporadically (but too often), and I have no idea why. The whole purpose of my post is to find anything that will help me troubleshoot the problem further.
    – kjo
    Oct 6, 2023 at 16:46

2 Answers 2


A couple things you can do. The first one is by far the more important one, and it should be tried first.

  1. Do you see the same problem if you start Emacs with emacs -Q? If not, bisect your init file, to find the culprit.

    Yes, if the problem is intermittent and starts only after quite a while then this check can be a pain to carry out. Nevertheless, it's essential to narrow down the search space before trying other troubleshooting. If your init file loads a boatload of stuff then all of that expands the search space.

  2. M-x debug-on-entry other-buffer, then step through the debugger with d when the debugger opens.

    This too is a pain. But it will let you see what other-buffer does each time it's called. You can also use c instead of d, to skip through the details of a given evaluation step.


One possibility:

C-hig (elisp)Buffer Parameters (which is within the "Frame Parameters" section of the manual) says:

     The buffer-predicate function for this frame.  The function
     ‘other-buffer’ uses this predicate (from the selected frame) to
     decide which buffers it should consider, if the predicate is not
     ‘nil’.  It calls the predicate with one argument, a buffer, once
     for each buffer; if the predicate returns a non-‘nil’ value, it
     considers that buffer.

You could query that with:

(frame-parameter (selected-frame) 'buffer-predicate)

Normally it would be nil but if it wasn't then that might potentially explain strange behaviour.

  • 1
    Thank you for the suggestion. But I got nil just now when I tried it.
    – kjo
    Oct 7, 2023 at 0:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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