Native frame transposition coming to Emacs 31

> Your local web gangster

> My name is Pranshu, I'm currently an highschool student, on the way to become a proffesional freerider. I am ethniclly Indian(half Bihari and half Punjabi, for my brown brothers), you can find me in Brisbane, Australia, probably bathing in a public fountain.

Haha, so lovely. Reminds me of older times when the internet was cool and weird.

We've been seeking proof for years that Emacs still attracts new users--finally found one :D

> Knows Perl/lisp/zig/ruby/C++/python, in order of most to least proficiency

Whoa. A highschooler who prefer Perl & Lisp.

I think this kid has a very promising freeriding career ahead of them

Not much. A horizontal split (C-x 2) can be quite useful to keep the top of a file in view while editing around at the bottom of a file. A vertical split (C-x 3) is useful when comparing files side by side. But that's about as far as I go, beyond that it just becomes annoying, as popups like from magit will show up in random subwindows, often rendering them unusable, due to that subwindow not being big enough.

The default setup I've been using for years is to dedicate a desktop to emacs, break it into 3 windows horizontally, and then each of them fluidly switches between being full-frame in its bit and being cut in half. That gives me up to six contexts to operate in at once, though it's certainly some sort of code smell to need that many for some particular task! But 2, 3, and occasional dips into 4 are pretty common, as well as having something open for other reasons.

This is also part of why I try to mostly, but not super pendantically, maintain the discipline of keeping lines under 80ish characters most of the time. Occasional spill is no big deal but constant spill gets hard to read in this context.

Partially this is just out of habit of many years, but lately it's becoming an actual advantage. My most recent project has me diving through multiple codebases, none of them in the same language; I've followed some interactions through Perl, Java, PHP, and Typescript codebases in quick succession. Both having the multiple contexts, that I have years of muscle memory using, and not needing to load up separate IDEs for each of them has turned out to be really advantageous. Emacs may not be the "best" at handling any one language but I don't think there's much better at trying to handle all of them simultaneously.

You are not alone. I've spent a lot of time over the years configuring Emacs not to split the frame unless I explicit ask for a split with C-x 2 (which I do very rarely). The first 6 ways I found to do it stopped working over the 33 years I've been using Emacs, so now I'm on version 7, which consists of (setq display-buffer-alist '((".*" (display-buffer-same-window)))) plus my own definition of compilation-goto-locus.

If I were a better Emacs citizen, I would lobby the maintainers to fix compilation-goto-locus so that it obeys display-buffer-alist like every other part of Emacs (that I know about, except for the *Completions* buffer, which does not need to be fixed IMHO because the *Completions* window reliably deletes itself when the user aborts or exits the minibuffer).

On my large screen, I find that having two windows is often quite useful. Sometimes three, but not for long.

Main use cases are:

  * Look at a "template" file as I'm working.  
  * The "occur" window 
  * Really, any grep output
  * Compilation window (This is how I run all tests)

For reading anything of length, I like to split horizontally into three balanced windows [1], put the buffer in all of them, and `M-x follow-mode'. At that point, I get a nice columnar display that makes better use of the screen real estate.

If you do this, you can make paging snappier and more predictable like so:

  (setf scroll-preserve-screen-position t)
  (setf next-screen-context-lines 0)

---

[1] That is, three windows of the same size side-by-side.

I usually have a vertical split, because it is useful to be able to refer to something else (e.g. other code, docs) while I work on my main task. I'll often have a pop up with a terminal or similar than I can bring up or dismiss with Doom shortcuts. That usually lives at the bottom. Occasionally three windows side by side is useful.

I cannot imagine using the features discussed in TFA though. They don't seem to solve anything for me.

Beyond the obvious answer (looking at two files at once, or a shell, or compilation buffer, or docs), I have a much simpler reason. My monitor is wide enough that if I have only one window, then all the text will be on the left end of the monitor, which means I'm constantly turning my head to work, leading to neck strain.

So even if I'm working on one thing, I do C-x 2 and use the right window, because then the beginning of the text is aligned to the center of my screen.

Yes, this is because I insist on running Emacs maximized.

I'd love to use more than one window, but they're completely unpredictable and really hard to configure the way you want. Magit buffers will open in one way, Cider Error buffers open in some other way. And the behavior will also change based on your frame size... You can sometimes configure them, but only from the limited behaviors provided by the package itself. The behaviors are different in different packages and there is no configuration/coordination in the "runtime"

For those that don’t know. Emacs was there before windows managers was the norm (I think), so after splitting the emacs view, each part was called a window.

The whole view is called a frame and store the window layout. You can create as many frames as you, each with its own layout and in terminal mode, they would swap like i3 workspaces. But in graphic mode (GUI) they are what we call window today, what emacs users refer as windows would be panes.

It operates on frames, moving the windows inside them, similar to how transposing a matrix moves around the values it contains.

Sway/i3/etc?