4

Is there a good way to manage multiple windows in a large frame?

I usually have one large frame, split into many windows, and I find that when I (or some command) visits a buffer, the choice of window that will display the buffer is somewhat random. Sometimes it chooses a window that I'd like to keep its current buffer, sometimes it makes a new window, etc. All reasonable behaviours, but a bit annoying.

The only resources I've found are display-buffer-alist and set-window-dedicated-p, but they are not very convenient. For example, if I make a window dedicated, then I can't make it show a different buffer without undedicating it by hand.

On the other hand, I can use display-buffer-alist to decide whether a buffer should make a new window/frame, or reuse or split some window, but it's difficult to control which window it uses. It mostly seems the use the least recently used window, but that's not a meaningful heuristic for my setup because I can easily have multiple important windows that I look at, but don't interact with.

Any suggestions?

Improve this question
11
  • I am unable to understand what you mean by "when I switch to a buffer, the choice of window that will display the buffer is somewhat random". When you switch to a buffer (I use ido for quick switching), the switched-to buffer appears in the same window from where I initiate C-x b. Also, I didn't understand what you mean by "Sometimes it chooses a window that I'd like to keep its current buffer, sometimes it makes a new window, etc.". You can try ace-window if you want to jump to a particular window.
    – Kaushal Modi
    Commented Jan 9, 2015 at 21:22
  • @kaushalmodi Some commands create buffers of their own (magit-status is especially common, also trace output, backtrace, compilation output), and those buffers have to go in some window somewhere, C-x b is not the only way to switch to a new buffer. I don't understand what's unclear about the second quoted sentence: it reuses an existing window that I would not like to see reused.
    – Kirill
    Commented Jan 9, 2015 at 21:28
  • It was unclear because you mentioned that those random things happened when you "switched to a buffer", which I associate to the action that happens on doing C-x b. Are you sure you are switching buffers and not creating new buffers?
    – Kaushal Modi
    Commented Jan 9, 2015 at 21:33
  • 1
    This (How do I force a specific buffer to open in a new window?) is how I trained one of the magit buffers that was bothering me when being created.
    – Kaushal Modi
    Commented Jan 9, 2015 at 21:36
  • 1
    +1 for all that you wrote. It's a great question, and I second the "inconvenience" characterization of `display-buffer-alist' and the near uselessness of the lru window. I hope you find some satisfactory answers here (or somewhere), but I kinda doubt it.
    – Drew
    Commented Jan 9, 2015 at 22:26

1 Answer 1

Reset to default
5

I also had difficulties with managing windows in a large frame, so I wrote this package named Purpose, which uses display-buffer-overriding-action to manage windows instead of display-buffer.

Basically, it adds a "purpose" to buffers and windows, so you can have windows that are used for editing (e.g. for source files), windows for comint-based buffers (e.g. terminal, REPL), etc.
So if you have 3 python files and a bash terminal open (a total of 4 windows), and you open an interpreter from python (C-c C-z), the interpreter will be displayed instead of the terminal for sure.
You can also configure which purposes exist, if the default configuration is not good enough for you (e.g. if you don't consider python and elisp buffers to have the same purpose).

The package is quite new, so it may have a few issues, but I think it could work for you. Hope this helps.

P.S. Sorry for promoting my own package, but I don't see any other answers here at the moment...

Improve this answer
2
  • is this package called "window-purpose" in MELPA? I'm ready to try anything. Emacs is driving me crazy replacing my windows with buffers of other Python files while I'm trying to test code.
    – pauljohn32
    Commented Apr 16, 2019 at 22:39
  • If your package is "window-purpose" on MELPA, I must say it is working well for 10 minutes now :) I mean it is awesome. This really helps with ESS and Elpy.
    – pauljohn32
    Commented Apr 16, 2019 at 22:49

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.