Demystifying Emacs's Window Manager

I was more than a little surprised to discover that `display-buffer-in-tab` creates a tab as a *side-effect* so you can use it to pre-empt further window actions in a new tab. Neat, but... totally undocumented. So aside from `display-buffer-alist`, I can't really think of any other variable with such a complex surface area except for the font face stuff.

Awesome article. Thanks for sharing.

Great article! As always. There is certainly a lot to take in here :). Thanks for writing and sharing it along with your scripts, too.

> But there’s a large body of up-to-date packages that don’t create or manage windows correctly even when it’s most likely easier to do so. > If you encounter such a package – they are more common than you think – you have little in the way of recourse beyond working around the code, or raising an issue with the maintainer(s). I end up having to do the latter about once a month on average. Among built-in packages, the worst offender is org mode, which I had to heavily advise until `switch-to-buffer-obey-display-actions` was introduced. (This doesn't really help because org insists on clearing the frame and restoring the previous window configuration after.)

Matching _new_ buffers by major mode in display-buffer-alist is pretty hit or miss, since many packages (built in or otherwise) set the major mode after they call display-buffer. After a few instances of this I just started matching everything by name regexps.

I was on my fourth attempt to wrangle this, the new straw (always something different each time I give up...) were vc-mode and magit. Neither worked very well with the "show diff|show files and commit message". Couldn't get neither to display properly and ended up rolling back display-buffer-alist once again. But this time my setup was better than ever!

Good info, as usual. > Emacs is a fantastic ***tiling*** window manager, and not enough people know that. Yes, well, a tiling window manager doesn't really present the be-all and end-all of window management. It is what it is. And yes, Emacs and other UI-presenting apps are limited wrt manipulating window-manager windows (precisely because they're ultimately window-manager managed). Emacs does pretty much all that's possible in the limited dimension/space of a window-manager window, and that's pretty good. But tiling is limiting. > *"There, it’s out now; I said it; now everybody knows."*

Appreciate the article. > Use it to instruct Emacs to always open, say, Javascript files in existing js-mode buffers. Unless I'm misunderstanding, you probably meant: > Use it to instruct Emacs to always open, say, Javascript files in existing js-mode windows. Or: > Use it to instruct Emacs to open, say, Javascript files in windows which contain existing js-mode buffers.

Tiling is limited compared to what?

Thanks so much for this article. I've been a `frames-only-mode` user for quite a while, but have been planning to dig into window management and use fewer frames for a while now. This really helps make sense of it all.

Compared to being able to tile but not have to tile. Being able to use window-manager windows (Emacs frames) easily, getting them to do whatever you want, as well as Emacs windows within them. Do you use a tiling window manager? I don't. Do you prefer a tiling window manager? I don't. Whatever you can do with tiling you can do without being limited to it, i.e., tiling within a frame (or the whole screen) is a subset of what you can do with frames or the whole screen. Tiling is just one way to use the available space. Its way is to exclude being able to overlap windows (frames), and to use all of the available space in its allotted rectangle. That's a fine possibility, but it's limited - in that particular way.

> because they're ultimately window-manager managed spotted the person who hasn't experienced the full glory of exwm yet.

Isn't tiling limited by definition? It's made of limits.

> "They’re given the cryptic name *atomic*." I am guessing that word "atomic" does not describe the windows in the group, rather it describes the *function* over the multiple windows in a group. As in, the function performs a single action on all windows in the group within a single "atomic" time interval.

Valid points, for sure. But you're also Mr. Frame ;) I've read your detailed frame-based workflow on the wiki a number of times. I take it you had a lot to do with liberating Emacs from the yoke of its only frame, back in the day?

Yeah I can imagine. It's understandable that some older packages have a battle-tested window layout scheme, especially as the older system was... not very good. I like Magit (and the like's) approach of making it a `defcustom`.

Yeah, that risk will never abate. The only thing that might is some sort of `save-excursion`-style form used in `display-buffer` that collects all the window and mode settings and delays application until it exits. But that no doubt has many downsides also.

Very illuminating article, definitely takes me closer to understanding the system. However, my limiting issue every time I look at this is probably not *how* to configure it (though that has given me trouble), but instead *what* to configure. I can never work out how I *want* things to function.

There I was sure (before following the link) this was going to be about EXWM. Still, full of good information. I am excited to try `(setq switch-to-buffer-obey-display-actions t)` and she if it removes or creates bugs for EXWM.

Thanks. All fixed.

Hello, Mickey! No, I've had nothing to do with liberating Emacs from anything. ;-) And the limitations of Emacs manipulation of frames are from two sources, I think, and the first one is partly behind the second: 1. Window managers have ultimate control over window-manager windows, including Emacs frames. And window managers differ in their behavior in this regard. 2. Few Emacs developers, especially "core" developers, use frames much. So improvement of Emacs management/support of frames hasn't received a lot of attention. My only points here are: 1. Agreement that Emacs is now much better wrt letting users and code display Emacs windows than it used to be. Yes, it's a good tiling window manager. 2. Tiled windows is only one way, and not necessarily the best way, to display them. Emacs essentially works within the box provided by the limitations of a tiling window manager.

I use Emacs on/with MS Windows. So no, Exwm does nothing for me. But how about you provide a great tutorial for everyone about how to use Exwm to get rock-solid, flexible, keyboard-driven, user-friendly user manipulation of Emacs frames with Exwm? Have I spotted the person who will do that? ;-)

"My potions are too strong for you, traveler. You should go to a seller who sells weaker potions." https://www.youtube.com/watch?v=R_FQU4KzN7A

I had a setup that worked perfect for job--, and I rolled it back a couple times because I kept finding challenges here and there. But now I am at a different place and after reading this article I realized...I don't know what window configuration would work for the tasks I do now! For example, I used to have shell in a sidewindow, but nowadays I need to use shells to log into containers or remote hosts and tail some logs. The small sidewindow at the bottom of the screen would be no longer useful... So, reading your comment a few days ago, made me realize, I am on the same boat, and I kept thinking about it, now I see I just doesn't make any sense to bother with windows configuration at all.