how big is the screen ?

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.

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 value mostly screen space dedicated to the one thing I am doing.

Sure, but that's like ... what? Half the screen in the best case scenario?

The other half is whitespace, so it makes sense to see the rest of that file in the other half.

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.

I only use C-x 1, C-x 2 and C-x 3, seems like that covers 95% of my use cases at least.

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.

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

For many of the websites that I use, this arrangement combines nicely with eww to make a very screen-efficient browsing experience.

---

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

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.

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.

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.

I tend to use emacs from within screen(s), and use screen for the layout, but I think I might need to reconsider when 31 hits!

I have a 42" 4K TV I'm using as a monitor and need to split it into multiple windows to make effective use of it.

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

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.

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.

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"

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

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.

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.

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

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.

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

Two windows are invaluable when doing diff, ctrl-F2 to navigate both windows to the differences in both windows.

I can quickly go over the content of the files in a directory with one window in dired mode and another for visiting the files.

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.

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

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

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

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

Whoa. A highschooler who prefer Perl & Lisp.

Sway/i3/etc?

I added `C-M-0` for flip and `C-M-=` for rotate, so far liking it.

Oh yeah, and I generally keep such a monster running in a GNU screen via mosh on servers too. Loverly! They can run for years.