The Emacs Window Management Almanac(karthinks.com)
karthinks.com
The Emacs Window Management Almanac
https://karthinks.com/software/emacs-window-management-almanac/
37 comments
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.
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.
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.
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
Though now I also found https://git.sr.ht/~wklew/golden
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.
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.
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.
But tbh it's actually pretty powerful and sufficient for my purposes and I wish the various tiling window managers were just that.
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!
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.
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.
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.
Yes. Same for me as well. It just works and is easy for my fingers to remember without consciously thinking about it.
Similarly. I do have
But it's nice to have such an in-depth reference, Karthik's articles are always very educational and interesting.
(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.
I use the <apps> key, usually I hit it with the base of my right hand.
Something I’d like to add to Karthink’s notes on `windmove-mode`: you can set `windmove-default-keybindings` to move through windows with Ctrl-<arrow keys>
[1]: https://codeberg.org/ashton314/emacs-bedrock
(windmove-default-keybindings 'control)
[1]: https://codeberg.org/ashton314/emacs-bedrock
Just checked my .emacs and I am doing exactly the same. I prefer over C-x O since it is one key less to press and more flexible.
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.
(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.
> 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!
Unless you have a browsers that does exactly that (e.g., Vivaldi), allowing you to view multiple pages at once!
I use a Brave extension that opens always a new window. Window management is then left to my WM, XMonad.
Wouldn't you lose tab hibernation? Also with dozens of tabs does this not pollute the WM?
> 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.
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.
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.
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.)
(I'm not using a HiDPI monitor, just a 1080p one.)
This article is very in-depth and I really like that the author took the time to draw good diagrams.
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
"zygospore lets you revert C-x 1 (delete-other-window) by pressing C-x 1 again"
https://github.com/LouisKottmann/zygospore.el
You might want to investigate winner mode for redoing and undoing all window configuration changes:
https://www.emacswiki.org/emacs/WinnerMode
https://www.emacswiki.org/emacs/WinnerMode
Ideally, ahouldn’t it be undo?
I suppose that would be weird, but c-u c-x 1 would be consistent.
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
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
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.
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.
I just liked the definition of DWIM in that article. I don’t think DWIM operates in Emacs Lisp the way it did in Interlisp, and zygospore’s not exactly a good example, but I’ve come across ‘-dwim’ versions of commands that combine the functionality of multiple ones and try to deduce which particular functionality you wanted from the surrounding context—it’s nice.
Then what is DWIM for you? What did you want to disable in Interlisp? For me the concept does indeed have nothing intrinsic to do with Lisp.
DWIM in Interlisp was an automated error handler for Lisp code. It would be triggered on errors and then tried to guess possible fixes at runtime (misspelled functions&variables could be corrected, ...).
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).
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).
In case the author sees this, I enjoyed the nod to the Acme editor.
Hi. I want to call hledger-balance-sheet and have it open to the right at 30% and leave my .hledger.journal open on the left,and selected, instead of replacing it.
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.