I find myself very rarely using window features of emacs. Am I missing out on something? I value mostly screen space dedicated to the one thing I am doing.
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.
As a counterpoint, I pretty much always split into 2+ windows. A 2-window setup is a code + terminal setup with shortcuts to run commands on the terminal(s). On more complex projects there are typically more than one terminal windows.
My org-mode emacs instance for note taking is split into quite a few windows: ongoing work task(s), generic "today's scratch pad", various topical notes files, etc.
On the posted topic: I don't know whether the transposition would be useful for me though - as the layout is set up by screen orientation then only a 180 degree turn would make sense.
Looks incredibly complicated, or maybe the article isn't written very clearly. It sounds like the packages are doing their own layout and you can override it from a central location .. Sometimes
Seems like this new feature might help with that, if magit takes over or creates a new window, you can rotate or flip your window arrangement until it's in a usable space (if it works like most tiling window managers, which isn't entirely clear from TFA).
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)
I'd love to have it so that "output" is in the other window at all times. I haven't really found a way for that to work, too well. Especially since often working on websites. The idea behind skewer-mode is really enticing to me. I have yet to actually make that work, though.
* Implementation/header pairs in C++
* Language REPLs (e.g., Python)
* Quick calculations in Calc while coding
* Checking dates on the calendar
* Magit status
* Diff buffers (especially diff-buffer-with-file)
* Listing neighboring files with dired
* Notes on a code base/task in an Org mode file
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:
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"
Do you never refer to other files or documentation while working? Or use a REPL? Sometimes I even refer to the top and bottom of the same file simultaneously.
I have more than a dozen special commands for splitting to multiple n*m windows filled with different types of buffers or transposing existing window splits; I occasionally need a split into 4x4 or 5x5 or even more windows to quickly/visually find the shell that logs something of interest to me. It is not neccessary, really, but occasionally helpful. I often switch between 1x3, 2x3, 2x4, or 2x2 layouts that it was worth putting in the time to organize all these splits and then adding some more felt easy and useful. My three different main monitors (home/work/laptop) often require different optimal splits and depending on the focus mode, fonts, or the presense of a browser window I may again need differnet splits. I often find it helpful to have follow mode on a 1x3 setup either a single document to have focus over a larger context. The main reason for all the splits, however, is managing several dozens of shells or code files.
I almost always have two side-by-side windows (C-x 3), usually when I'm writing a function I'll have the function on one side, and the other side is where I'm calling the function. So both windows change buffer constantly as I navigate a codebase.
I keep one window (in the common OS meaning of window) per virtual desktop and I usually split it into two horizontal buffers. Sometimes I split it in two vertical buffers, for comparing lines. Sometimes even in four, two rows and two columns per row. I can fit 55 lines into my emacs, plus the minibuffer, the status line above the minibuffer and the menu and title bar on top so even split in four buffers each of them is about the same size of the terminals I grew with. And I'm using proportional fonts, that are more readable and space efficient.
Depends on how you like to code. I have two full screen frames on their own monitors with 5 or 6 side-by-side windows, and a stack of three vertical split windows on one side.
I like to have the side-by-side windows looking at different files (unless I'm in a really long file) and the stack of windows have vcs, messages, and sometimes eglot
Well you could see multiple buffers on screen simultaneously, rather than just one? But if you don't want that, then there's no point. And anyway, the point of Emacs is that you can do what you like, and customize it to work well for you.
My most used is winner-mode. It's just undo / redo, doesn't provide any new logic, but allows to quickly goes back to the layout state before you maximized a buffer. Bound to S-b for winner-undo and S-n for winner-redo IIRC.
More than two is a bit painful, in my experience, as I don't think Emacs has directional focus like the usual X11 WMs (e.g. i3, bspwm) and C-o works well with only two.
Magit and sly/SLIME work much better with a second window, I'd say.
It does, but I don't think they have default bindings. The commands are windmove-{left,down,up,right}. I've had them bound to C-S-{h,j,k,l} for years and it makes moving around much more fluid and predictable than C-x o.
Most of the time I have 4 or 6 buffers visible at once, including the REPL and files I’m editing - and that’s when I’m working on “one thing”, having packages like transpose frame or ace-window makes this type of workflow much easier
For a while I used dired-sidebar-show-sidebar and dired-omit-mode to give me a list of files in a narrow window on the left. I kept messing it up with C-x 1, though.
Just a comment in solidarity; I came here to ask the same question. :)
I think my big problem is: I need a native terminal program, and I'm almost always using a terminal for something while I'm using Emacs. Which means I can't dedicate a whole screen to Emacs.
I for one often split the window in two to have like an API definition and the implementation up at the same time, or to have a terminal and a script I'm running both visible, or such.
