Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Emacs Window Management Almanac

karthinks.com

Post reply on HN
Print view View original

21–30 of 38 posts

Re: The Emacs Window Management Almanac

#21

Post by syene »

gumby wrote: post #8
chungus wrote: post #6

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

Ideally, ahouldn’t it be undo? I suppose that would be weird, but c-u c-x 1 would be consistent.

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

Re: The Emacs Window Management Almanac

#22

Post by cmrdporcupine »

nextos wrote: post #13
celrod wrote: post #4

Earlier quoted context omitted.

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.

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.

But is there a reasonable way to handle emacs buffers inside stumpwm?

Re: The Emacs Window Management Almanac

#23

Post by jackcviers3 »

ww520 wrote: post #17

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 (- (truncat…

golden-ratio works for this as well.

Re: The Emacs Window Management Almanac

#24

Post by medstrom »

jackcviers3 wrote: post #23
ww520 wrote: post #17

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 (- (truncat…

golden-ratio works for this as well.

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

Re: The Emacs Window Management Almanac

#25

Post by emporas »

jackcviers3 wrote: post #23
ww520 wrote: post #17

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 (- (truncat…

golden-ratio works for this as well.

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.

Re: The Emacs Window Management Almanac

#26

Post by hollerith »

hollerith wrote: post #18
dctoedt wrote: post #16

Earlier quoted context omitted.

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

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.

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

Re: The Emacs Window Management Almanac

#27

Post by gumby »

syene wrote: post #21
gumby wrote: post #8

Earlier quoted context omitted.

Ideally, ahouldn’t it be undo? I suppose that would be weird, but c-u c-x 1 would be consistent.

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

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.

Re: The Emacs Window Management Almanac

#28

Post by jbstack »

dctoedt wrote: post #16
hollerith wrote: post #9

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 nev…

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

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.

Re: The Emacs Window Management Almanac

#29

Post by nextos »

cmrdporcupine wrote: post #22
nextos wrote: post #13

Earlier quoted context omitted.

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.

But is there a reasonable way to handle emacs buffers inside stumpwm?

Yes, absolutely. There are several StumpWM modules providing integration with Emacs. You can also roll your own functions.

Re: The Emacs Window Management Almanac

#30

Post by BaculumMeumEst »

jackcviers3 wrote: post #23
ww520 wrote: post #17

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 (- (truncat…

golden-ratio works for this as well.

I think zoom-mode is the more recommended package for this functionality nowadays, but I will defer to someone who knows more. I just know golden-ratio was a little jank when I tried it recently, but zoom works well.
Post reply on HN