Sometimes the evenly split windows don't cut it. I put the following function in the init.el file and bind "C-x 7" to it to adjust the current window and its peer to 70% and 30% sizes vertically. Same for horizontally with a "C-x 8" key binding.

    (defun partial-size-window ()
      "Set the two split windows to 70% and 30% vertically."
      (interactive) 
      (let ((size (- (truncate (* .70 (frame-height))) (window-height)))) 
        (if (> size 0) 
            (enlarge-window size))))

    (defun partial-size-window-h ()
      "Set the two split windows to 70% and 30% horizontally."
      (interactive) 
      (let ((size (- (truncate (* .70 (frame-width))) (window-width)))) 
        (if (> size 0) 
            (enlarge-window-horizontally size))))

What i have not found a solution yet, is when one window is expanded to 75% of space, then it collapses to 25%, the notes i wanted to focus on get moved up or down. After some trial and error i put my cursor somewhere downward not far from the text i want to be displayed, and most of the time it gets displayed after collapsing the space.

I have yet to figure out how to select a region, and golden ratio keep that in display after rebalancing.

ace-window and ace-window-display-mode

frames-only-mode

I admit my guilt: in about 40 years of using Emacs I mostly have always just used next-window, creating new windows under or next to, and when working on remote servers relying on tmux.

     (global-set-key (kbd "M-o") #'other-window)

But it's nice to have such an in-depth reference, Karthik's articles are always very educational and interesting.

But tbh it's actually pretty powerful and sufficient for my purposes and I wish the various tiling window managers were just that.

(The way I achieve that has changed over the years because the old way stops working.)

The way I do it now, the frame does split in some situations (e.g., when Emacs shows me a *Completions* buffer) but AFAICR I never need to manually invoke the delete-window command to get rid of the second window: it always goes away by itself.

Unless you have a browsers that does exactly that (e.g., Vivaldi), allowing you to view multiple pages at once!

Is that to address a particular problem?

I use multi-window frames a fair amount. (Latest Mac OS, latest Emacs.) I've noticed that sometimes a multi-window frame will seemingly freeze up and be unresponsive to the keyboard or trackpad, including multiple Ctrl-G commands. But then C-x 5 2 will work to create a new frame. And I can go back to the frozen frame and C-x 5 0 to kill that frame.

(I'm not using a HiDPI monitor, just a 1080p one.)

It seems like a Vim or a Kakoune thing to get stuck up attaching strict logic to the “command language”. Lisps have a concept of do-what-I-mean (DWIM)—the computer anticipates what the user intends to do, overlooking trivial errors.† There’s some subjectivity involved in making commands do-what-[you]-mean, but what’s the point of ‘C-x 1’-ing after we’ve just ‘C-x 1’-ed anyway? None. So why not make that into a convenient way to undo the previous ‘C-x 1’?

The ‘undo’ command only acts on changes in buffers, and there’s always winner-mode and its undo, but as a zygospore user—it seems very natural from the get go. I repeat the ‘C-x 1’ if I press it accidentally, and more often I find myself temporarily magnifying a buffer to take up the whole screen to do some focussed editing, which I can come out of with another ‘C-x 1’ (as long as I don’t change the window configuration further).

†: from https://en.wikipedia.org/wiki/DWIM

Of course the general concept was taken up elsewhere as well and is used to excellent (and terrible — I’m looking at you, Apple spelling autocorrect) effect.

That Wikipedia article you cited is weird. Even the example cited, the file reference DWIM, is a rather degenerate case that has nothing to do with lisp itself. Certainly DWIM doesn’t operate on the execution of emacs lisp, despite the article’s hand-wavy attempt to imply so.

Though one might expect a bigger picture: "interacting with an agent who attempts to interpret the user's request from contextual information" (Teitelman/Masinter, The Interlisp Programming Environment, 1981).