Actually utilizing `next-buffer` and `previous-buffer` makes emacs much nicer to use

Before I was defaulting to always using \`switch-to-buffer\` and selecting things manually and thought it was just fine to do that. Then I started using \`next-buffer\` and \`previous-buffer\` and developing an intuition for what buffer would show up. It's made my experience of using emacs drastically better in the same way that learning \`ctrl+tab\` and \`ctrl+shift+tab\` in web browsers made my browsing experience better. Maybe these kinds of feelings are very subjective, but I feel like this one might generalize to others experiences well. By default they are bound to \`C-x <left>\` and \`C-x <right>\`. Feel free to also share any similar other "wow this makes buffer management so much nicer feeling to use" experiences you've had.

I have "next-buffer" mapped to F2 and "previous-buffer" to F1. I use them all the time. There are various quite efficient ways of dealing with multiple buffers. Actually, using the same shortcuts you use in a web browser is a good idea. I really like using the same shortcuts across different software.

I bind "C-x p" to a helper that calls `(other-window -1)` as a inverse of "C-x o", letting me move forward or backward through the windows easily. I've never had much issue with just using "C-x b <enter>" to quick switch or use "C-x b + bit of name + tab completion" to actually change what buffer a given window points into. How many buffers are you keeping open at once? Or do you just prefer having one big window and jumping between buffers in it?

XEmacs used to have a binding `C-M-l` for `switch-to-other-buffer`, which I've retained in my Emacs: (defun switch-to-other-buffer (arg) (interactive "p") (if (eq arg 0) (bury-buffer (current-buffer))) (switch-to-buffer (if (<= arg 1) (other-buffer (current-buffer)) (nth (1+ arg) (buffer-list)))))

I find `C-x` (release x) `<left>` `C-x` (release x) `<right>` kills the tempo of movement e.g. when switching backwards/forwards between 2 buffers, or cycling through several buffer. I re-bound those functions to `s-<left>` and `s-<right>` (the `super` key - often called the windows key). That way I can keep that key pressed and just switch quickly between buffer with the `<left>` & `<right>` keys. Cycling backwards/forwards between a few buffers is as smooth as silk now.

None of you are bothered by temporary buffers showing up with previous/next commands? I use helm and they really mess with it often

I use the `jh` chord to call `crux-switch-to-previous-buffer`. Don't think I could live without it.

Emacs has a built in function for this called `mode-line-other-buffer`

My buffer experience improved dramatically after I sat down and wrote a couple of functions to create arbitrary grids of windows with different buffers on my Emacs frame (I switch between these visible buffers in a number of different ways, avy or windmove.) I also get a lot out of a dozen bookmarked configurations of combinations of common buffers in particular window shapes. I organized ibuffer to group buffers by mode or names, which helps occasionally when the number of total open buffers approaches or exceeds a hundred or so. I started using project.el more often during the last year or so, so I sometimes go C-x p p, switch to a different project and then find file, magit, or shell (which is a lot of typing but may be faster than ibuffer). Sometimes it helps to use different machines for different projects but frankly handling the number of total open emacs servers on different machines that share parts of file systems can also get complicated.

I don't use helm, but you will undoubtedly be able to tell it not to do that.

Good tip thanks!

Huh, thanks!

I use below command to switch between two buffers, ```lisp (defun my-switch-to-previous-buffer () "Switch to previous buffer." (interactive) (switch-to-buffer nil)) ```

`ibuffer` for me. Bind to `<menu>`. My ibuffer config. A very minimal ibuffer: (add-to-list 'display-buffer-alist '("\\*Ibuffer\\*" (display-buffer-other-frame)) t) (setq ibuffer-case-fold-search t ibuffer-default-sorting-mode 'recency ibuffer-formats '((mark modified " " (name 150))) ibuffer-use-other-window nil ;; enable/disable opening ibuffer in another window ibuffer-always-compile-formats nil) ;; If non-nil, increase the redisplay speed, at the cost of loading the elisp byte-compiler (add-hook 'ibuffer-mode-hook #'ibuffer-auto-mode) ;; auto-update ibuffer result

Sort of related since it's about navigating between buffers. I used to `C-x <right>` to move to compilation buffer, position cursor on the path the error is coming from and then `RET` to switch to that file, however, I recently discovered that I can just use ```C-x ` ``` (next-error) instead and I have no clue how I missed that in the last 3-4 years.

Why is the name prefixed with mode-line?

Emacs already has built-in interactive functions *previous-buffer* and *next-buffer* which you can bind directly to keys.

Those keybindings are horrible though.

> Actually utilizing `next-buffer` and `previous-buffer` makes emacs much nicer to use I agree; I have mine on F10 and S-F10. I can also recommend learning and utilizing other-window commands, like kill buffer in other window, open in other window etc.. Those are also just as useful, and make Emacs so much nicer place to be. [Here is a thread I made here not so long time ago](https://www.reddit.com/r/emacs/comments/x0r0pe/share_your_otherwindow_commands/) where you can pick few useful by both other people and me, or if you prefer my collection from those in a [file you can download](https://github.com/amno1/.emacs.d/blob/main/lisp/extras.el). next-buffer/previous-buffer-other-window might be useufl too for some. Check also those send-to-windo-up/down/left/right functions. I find them quite useful and use quite often. If I have a buffer, and would like to open another file in a buffer on a side, I can other use open in other window or open in current window and send-to. Difference is the working directory, so Helm (or whatever you use) will offer different file completions. Of course, it is not only for opening files, you can just send any buffer on any side, even if you only have just one buffer, so the workflow is slightly different then the "other-window" workflow..

you could bind your own helper that looks for the next and prev buffers, but ignores them if they start with `*` probably be great till you try to fast switch with a `*shell*` :) you could just specifically allow for that one, however

Not sure if that's good practice or not (still "new" to emacs) but I kill them automatically when emacs starts for that exact reason

> How many buffers are you keeping open at once? Or do you just prefer having one big window and jumping between buffers in it? I never closed them until recently and know it was typically 50+. I do use one emacs window with lots of buffers, specifically now though with tabspaces so buffers are scoped per tab.

Yes! I actually bind next and previous error to M-n and M-p and make the errors wrap around. I also bind eglot's execute code action to M-RET. This combo lets me cycle through and fix errors with code actions super quick.

Yeah, I bound them to M-n and M-p just today... but realizing I just shadowed my existing bindings I posted about in my last comment in this thread :S

Thanks! I've been using other-window commands recently so these are useful and timely.

Aside: The annoyance you describe is one of the best simple "start using elisp to deeply customize emacs and fix annoyances“ examples I've come across.

I tend to segment work into different emacs instances, each open on its own virtual desktop. We certainly have very different workflows.

No clue, the function has nothing to do with nor does use anything related to the modeline, for instance here is how it's implemented (defun mode-line-other-buffer () "Switch to the most recently selected buffer other than the current one." (interactive) (switch-to-buffer (other-buffer) nil t))

I have them mapped the same as on [ratpoison](https://en.wikipedia.org/wiki/Ratpoison), which lets me use Emacs and window manager pretty much the same way.

Sorry. the command's name might be a bit misguiding. The command switches between current buffer and recent buffer. This technique is very popular in many distributions.

You can fix this by setting `switch-to-prev-buffer-skip` to a function that checks for unwanted buffers, here's what I use (defun helm-buffer-p (window new-buffer bury-or-kill) "Returns T when NEW-BUFFER's name matches any regex in `helm-boring-buffer-regexp-list'." (cl-loop for regex in helm-boring-buffer-regexp-list when (string-match-p regex (buffer-name new-buffer)) return t))

> Sorry. the command's name might be a bit misguiding. I just tested. That has effect as calling previous-buffer, and next time when it is called, as calling next-buffer. Indeed, can be nifty, saves a key. I wasn't aware swicth-to-buffer could be used that way :). Thanks. Maybe call it 'last-buffer'? (defun last-buffer () "Switch to last used buffer." (interactive) (switch-to-buffer nil))

First time you Helm again, it will re-create them. It is also probably not good practice either. Some Helm-application might be written poorly and assume that some of Helm-buffers exists, and then you have a problem. The answer from /u/DistinctAnteater200 should be the way to do it.

There is also [iflipb](https://github.com/jrosdahl/iflipb). It sorts the buffers by recent usage so switching to the last used buffer is always one hotkey activation and successive activations continue the list. It also displays that list in the minibuffer and can filter it. It helps me to predict which buffer I get when pressing my hotkey and makes working with a couple buffers more enjoyable.

This only works well when your buffers can be counted on the fingers of one hand. When you have 130, ibuffer works much better.

The related commands `mode-line-previous-buffer` and `mode-line-next-buffer` are by default bound to mouse clicks on the buffer name in the mode line. Presumably `mode-line-other-buffer` was intended as another option for one of those bindings

If they are separated by project/tabspace I'd imagine for context switching one mighr use ibuffer but next and previous buffer would be useful while moving in the same context.

For that, you’d need `next-buffer` and `previous-buffer` to be constrained to context, which they aren’t; and for there to be only a few buffer per context, while there are many more. E.g. my job project currently has 60 buffers and it’s only Monday evening.

Cool defun, though I like the default binding of `reposition-window`, which repositions the current defun in the current window.

Oh wow -- I knew it would be clobbering something these days (I must have been using that binding for 20 years), but I haven't come across `reposition-window`, that looks really cool!

I have the same approach with directional move of focus or windows. The window manager does it if non-Emacs windows have focus, or forwards it to Emacs if Emacs has focus, which in turn passes it back to the WM if it's already at an edge. It's a nice half-way house to EXWM.

Ratpoison is essentially Emacs-like, or screen-like, in it's interface, just uses `C-t` as prefix.

I'm using several methods to jump between buffers. ``` (global-set-key [(f2)] 'ace-window) ; Buffer switcher (by its number) (global-set-key [(control f2)] 'other-window) (global-set-key [(f5)] 'ibuffer) (global-set-key (kbd "C-x b") 'helm-mini) (global-set-key (kbd "C-`") 'switch-to-previous-buffer) (global-set-key [(control f5)] 'bookmark-bmenu-list) (global-set-key [(shift f5)] 'bookmark-set) ``` And, of course, `C-x <left>`, `C-x <right>`, and `C-x o`.

I use consult-buffer and it place previous buffer on top of the list by default. Bind it to `C-p` as i used to in vim long time ago