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))))
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.
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.
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.
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.
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>
(windmove-default-keybindings 'control)
I have this in my config (as well as in my minimalist (really minimalist) starter kit [1]) and it’s a game-changer!
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.
> 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.
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.
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.)
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).
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.
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.
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).
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.
reply