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?

Malabarba
  • 23,148
  • 6
  • 79
  • 164
Kirill
  • 1,009
  • 7
  • 20
  • 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 Jan 09 '15 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 Jan 09 '15 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 Jan 09 '15 at 21:33
  • @kaushalmodi If a buffer already exists, and some command visits it, the buffer is not created anew, so I would call that switching. (But not with C-x b.) – Kirill Jan 09 '15 at 21:36
  • 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 Jan 09 '15 at 21:36
  • @kaushalmodi As I said, I know about display-buffer-alist, but it is not very precise or convenient for managing many windows in a single frame. – Kirill Jan 09 '15 at 21:38
  • Yes, that is true. I'd also be interested in solution to that. – Kaushal Modi Jan 09 '15 at 21:46
  • 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 Jan 09 '15 at 22:26
  • There's the popwin package that gives you some control over these buffers. I wrote my own to try out a slightly different approach to the problem. If these come close to your idea of a solution, I could elaborate in an answer or chat (or even on the #emacs IRC channel). – wasamasa Jan 10 '15 at 00:08
  • My suggestion is to start slowly by picking whatever functions you use every day -- e.g., email related utility. Dig into the source code looking for words like display-buffer and "pop". Create you own new functions or modify the source code itself until you are happy with how it works. Most people don't do that and try to fix it after the fact, or try to come up with some generalized solution using the display-buffer-alist. You can make the display-buffer-alist let-bound for the duration of your custom function and tailor it to your precise needs. There is no one magic solution. – lawlist Jan 10 '15 at 00:49
  • There are a number of packages in the melpa repository which provide 'window manager' type functionality for emacs windows. For example elscreen elwm, e2wm and quite a few packages which add window management/manipulation functions, such as spaces, spliter and a few which just add some additonal functions. One of these might solve your problem or might provide enough examples/ideas to help you setup something which improves your situation – Tim X Feb 15 '15 at 00:15

1 Answers1

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

bmag
  • 1,713
  • 10
  • 12
  • 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 Apr 16 '19 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 Apr 16 '19 at 22:49