[HN Gopher] The Emacs Window Management Almanac
       ___________________________________________________________________
        
       The Emacs Window Management Almanac
        
       Author : dargscisyhp
       Score  : 123 points
       Date   : 2024-05-11 06:19 UTC (16 hours ago)
        
 (HTM) web link (karthinks.com)
 (TXT) w3m dump (karthinks.com)
        
       | mark_l_watson wrote:
       | That is a good exploration. I am on a mobile device right now but
       | I can't wait to try:
       | 
       | 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.
        
         | cmrdporcupine wrote:
         | I'm the same, 30 years & C-x 1/2/3 C-x o, and that's about the
         | extent of it.
         | 
         | But tbh it's actually pretty powerful and sufficient for my
         | purposes and I wish the various tiling window managers were
         | just that.
        
           | celrod wrote:
           | EXWM is ;). I used it for about a year, but ultimately found
           | the performance, and in particular a low language server
           | locking up the window manager, unacceptable.
        
             | smartmic wrote:
             | I just switched to exwm and I'm curious if the article will
             | teach me some tricks which might be useful there. My
             | initial experience is good but it is still a bit rough
             | around the edges. In other words, I have not yet found my
             | best configuration and workflows.
        
             | nextos wrote:
             | StumpWM uses Common Lisp, and can be setup to be nearly
             | identical to Emacs window management. It is also quite
             | performant. Out of the box, its configuration is pretty
             | nice already.
        
               | cmrdporcupine wrote:
               | But is there a reasonable way to handle emacs buffers
               | inside stumpwm?
        
           | sbrother wrote:
           | I've also been doing exactly that for 20 years and will
           | probably do it for 20 more years :) it works everywhere and
           | is perfectly adequate and flexible!
        
           | alakra wrote:
           | Yes. Same for me as well. It just works and is easy for my
           | fingers to remember without consciously thinking about it.
        
         | wegwerff wrote:
         | Similarly. I do have                    (global-set-key (kbd
         | "M-o") #'other-window)
         | 
         | since C-x o is a bit much, but I don't feel any need for all
         | these extra packages.
         | 
         | But it's nice to have such an in-depth reference, Karthik's
         | articles are always very educational and interesting.
        
           | trocado wrote:
           | I use the <apps> key, usually I hit it with the base of my
           | right hand.
        
       | chungus wrote:
       | nice writeup, I'd like to share a great complementary package
       | that has been indispensable for me: zygospore
       | 
       | "zygospore lets you revert C-x 1 (delete-other-window) by
       | pressing C-x 1 again"
       | 
       | https://github.com/LouisKottmann/zygospore.el
        
         | gumby wrote:
         | Ideally, ahouldn't it be undo?
         | 
         | I suppose that would be weird, but c-u c-x 1 would be
         | consistent.
        
           | syene wrote:
           | > ... c-u c-x 1 would be consistent.
           | 
           | 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
        
             | gumby wrote:
             | As far as Lisps go, Teitelman implemented DWIM just for
             | Interlisp (annoyingly it was the macro expansion engine so
             | you couldn't disable it). MACLISP and its derivatives never
             | had that misfeature.
             | 
             | 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.
        
       | hollerith wrote:
       | I configure my Emacs to avoid splitting the frame into multiple
       | windows -- similar to how a web browser never splits the browser
       | window into multiple viewports. (Also my Emacs never makes a
       | second frame.)
       | 
       | (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.
        
         | eviks wrote:
         | > similar to how a web browser never splits the browser window
         | into multiple viewports.
         | 
         | Unless you have a browsers that does exactly that (e.g.,
         | Vivaldi), allowing you to view multiple pages at once!
        
           | BenFeldman1930 wrote:
           | I use a Brave extension that opens always a new window.
           | Window management is then left to my WM, XMonad.
        
             | eviks wrote:
             | Wouldn't you lose tab hibernation? Also with dozens of tabs
             | does this not pollute the WM?
        
         | dctoedt wrote:
         | > _I configure my Emacs to avoid splitting the frame into
         | multiple windows_
         | 
         | 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.
        
           | hollerith wrote:
           | It is not to work around a bug. I do it because I am in the
           | habit of making the text (and other UI elements) big.
        
             | hollerith wrote:
             | For example right now I have Gnome configured to scale the
             | UI by a factor of 200%, which means that my display will
             | fit only a quarter as many UI elements (e.g., letters of
             | the alphabet, icons) as it would if I ran at a scaling
             | factor of 100%.
             | 
             | (I'm not using a HiDPI monitor, just a 1080p one.)
        
           | jbstack wrote:
           | For me, it doesn't make sense to have my application's
           | functionality overlap with my window manager. Having two
           | separate methodologies and sets of keysbindings to move and
           | switch between areas of the screen depending on what happens
           | to be in those areas is arbitrary and inconsistent. The way I
           | switch between Firefox and LibreOffice should be the same as
           | the way I switch between two text editing windows/frames. I
           | therefore prefer to use frames rather than windows in Emacs,
           | and let my WM handle them. For the same reason I've never
           | seen the appeal of tmux pane management. If I used a WM,
           | Emacs windows management, and tmux panes, I'd need three
           | different ways to manage what are essentially all the same
           | concept.
        
       | bloopernova wrote:
       | This article is very in-depth and I really like that the author
       | took the time to draw good diagrams.
        
       | ww520 wrote:
       | Nice article. Good explanation and good guidelines.
       | 
       | 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))))
        
         | jackcviers3 wrote:
         | golden-ratio works for this as well.
        
           | medstrom wrote:
           | yup, unlike the name implies, it does not only do the golden
           | ratio (1.618:1)
           | 
           | Though now I also found https://git.sr.ht/~wklew/golden
        
           | emporas wrote:
           | golden-ratio is very convenient. I also split the frame to
           | two windows at most, and most of the times i focus on one
           | window, and the other window takes just 25% of the screen
           | space.
           | 
           | 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.
        
       ___________________________________________________________________
       (page generated 2024-05-11 23:00 UTC)