Native frame transposition coming to Emacs 31
p.bauherren.ovh182 points by nanna 10 days ago
182 points by nanna 10 days ago
Kudos to the programmer, who is apparently still in high school: https://p.bauherren.ovh/
> Your local web gangster
> My name is Pranshu, I'm currently an highschool student, on the way to become a proffesional freerider. I am ethniclly Indian(half Bihari and half Punjabi, for my brown brothers), you can find me in Brisbane, Australia, probably bathing in a public fountain.
Haha, so lovely. Reminds me of older times when the internet was cool and weird.
We've been seeking proof for years that Emacs still attracts new users--finally found one :D
Actually, he's a 40+ year old person. His obsession with Emacs is what prevented him from graduating high school all these years :-)
He opened his ~/.emacs file as a Junior in High School. Says he'll be ready to close it as soon as he gets this particular edit just right
I mean, this and native compilation. And the new json parser that landed. And... (I'm sure I could go on.)
What it doesn't have is a marketing department pushing it. But it has plenty of new users. No?
Joking aside, you're right. It's easy to imagine that Emacs has stagnated, but there are regular releases with improvements, some of them important fundamental improvements like native compilation.
I recently saw a Reddit post in a vim subreddit about using AI for coding, the response was "we don't do that here". I saw the same thing in the Emacs subreddit, and there's like 10 different packages for AI integrations, and, allegedly, Emacs is state-of-the-art when it comes to AI interactions through the editor (if only the user can configure it correctly). It's something I've been meaning to try.
https://www.reddit.com/r/neovim/comments/1js30ep/whats_every...
I’m pretty sure that the answer you quoted was a joke, mainly because the topic of AI packages comes up all the time on that subreddit and people are starting to make fun of the same question that’s asked every other day.
Codecompanion (Zed-like experience), Avante (Cursor-like experience), and Copilot all exist and integrate well with the rest of the neovim ecosystem.
Vim is an editor with quite a good API for integration with other tools and I don't see how you can't build one for AI (and you can use python for the integration). Emacs will have it much easier as almost everything you need has a better interface there.
The irony that Lisp was and AI were almost synonymous before the AI winter, and now AI is back, the Lispers distance themselves from it.
gptel.el is straightforward to configure and comfortable to use. It is indeed opinionated in ways that don't exactly match anything else out there, but if that sort of thing bothers you, you should not expect a comfortable time at first with Emacs. I like it a lot.
This undersells gptel.el, because IMHO it does a really good job of feeling emacs-native: you can read from the minibuffer or active region; send outputs to the message area, another buffer, or replace the marked region; use buffers or files as context sources; build "tools" out of elisp, ...
I'm not surprised I undersell it. I try to take a few months to a year's break from programming once a decade or so, when I can, both for the sake of coming back with fresh eyes and because anything gets miserable if you do it hard enough for long enough. This seemed like a good time. So though I've installed and set up gptel and chatted enough over some Elisp to see that it's functional with local models, I haven't as yet actually used it in a serious way.
On that note, I'm not much in the Emacs blog/creator scene or ecosystem this decade, either. Do you know any good topical resources that might fit well with time spent mostly away from keys? I realize I may be asking quite a lot.
I don't follow that scene much, either, but I do subscribe to https://www.masteringemacs.org/ which has good roundups when new major versions come out. I also have several open tabs from there about various libraries I need to fold into my own emacs configuration.
The comment you answered is tongue in cheek, the joke being that emacs is for old people.
I'm an old person. I love emacs, no complaints here. Does this mean that when you are old, you will love emacs as well? Conclusion: in the long run, everyone loves emacs :-)
My favourite emacs-is-for-old-people joke is the backronym "Editor for Middle-Aged Computer Scientists".
> Knows Perl/lisp/zig/ruby/C++/python, in order of most to least proficiency
Whoa. A highschooler who prefer Perl & Lisp.
I find myself very rarely using window features of emacs. Am I missing out on something? I value mostly screen space dedicated to the one thing I am doing.
Not much. A horizontal split (C-x 2) can be quite useful to keep the top of a file in view while editing around at the bottom of a file. A vertical split (C-x 3) is useful when comparing files side by side. But that's about as far as I go, beyond that it just becomes annoying, as popups like from magit will show up in random subwindows, often rendering them unusable, due to that subwindow not being big enough.
As a counterpoint, I pretty much always split into 2+ windows. A 2-window setup is a code + terminal setup with shortcuts to run commands on the terminal(s). On more complex projects there are typically more than one terminal windows.
My org-mode emacs instance for note taking is split into quite a few windows: ongoing work task(s), generic "today's scratch pad", various topical notes files, etc.
On the posted topic: I don't know whether the transposition would be useful for me though - as the layout is set up by screen orientation then only a 180 degree turn would make sense.
perhaps i might interest you in display-buffer-alist ?
useful resources:
1. https://protesilaos.com/codelog/2024-02-08-emacs-window-rule...
2. https://www.masteringemacs.org/article/demystifying-emacs-wi...
3. <this space is for rent>
3. https://karthinks.com/software/emacs-window-management-alman...
(Additional useful knowledge)
Looks incredibly complicated, or maybe the article isn't written very clearly. It sounds like the packages are doing their own layout and you can override it from a central location .. Sometimes
> ... Looks incredibly complicated
you are not alone ! even the info-page has this: https://www.gnu.org/software/emacs/manual/html_node/elisp/Th...
Seems like this new feature might help with that, if magit takes over or creates a new window, you can rotate or flip your window arrangement until it's in a usable space (if it works like most tiling window managers, which isn't entirely clear from TFA).
The default setup I've been using for years is to dedicate a desktop to emacs, break it into 3 windows horizontally, and then each of them fluidly switches between being full-frame in its bit and being cut in half. That gives me up to six contexts to operate in at once, though it's certainly some sort of code smell to need that many for some particular task! But 2, 3, and occasional dips into 4 are pretty common, as well as having something open for other reasons.
This is also part of why I try to mostly, but not super pendantically, maintain the discipline of keeping lines under 80ish characters most of the time. Occasional spill is no big deal but constant spill gets hard to read in this context.
Partially this is just out of habit of many years, but lately it's becoming an actual advantage. My most recent project has me diving through multiple codebases, none of them in the same language; I've followed some interactions through Perl, Java, PHP, and Typescript codebases in quick succession. Both having the multiple contexts, that I have years of muscle memory using, and not needing to load up separate IDEs for each of them has turned out to be really advantageous. Emacs may not be the "best" at handling any one language but I don't think there's much better at trying to handle all of them simultaneously.
I do the same thing in Vim, which has turned me into the "please wrap to 80 cols" person, which I'm completely fine with haha.
You are not alone. I've spent a lot of time over the years configuring Emacs not to split the frame unless I explicit ask for a split with C-x 2 (which I do very rarely). The first 6 ways I found to do it stopped working over the 33 years I've been using Emacs, so now I'm on version 7, which consists of (setq display-buffer-alist '((".*" (display-buffer-same-window)))) plus my own definition of compilation-goto-locus.
If I were a better Emacs citizen, I would lobby the maintainers to fix compilation-goto-locus so that it obeys display-buffer-alist like every other part of Emacs (that I know about, except for the *Completions* buffer, which does not need to be fixed IMHO because the *Completions* window reliably deletes itself when the user aborts or exits the minibuffer).
On my large screen, I find that having two windows is often quite useful. Sometimes three, but not for long.
Main use cases are:
* Look at a "template" file as I'm working.
* The "occur" window
* Really, any grep output
* Compilation window (This is how I run all tests)
Good list. A few more for me:
* Implementation/header pairs in C++
* Language REPLs (e.g., Python)
* Quick calculations in Calc while coding
* Checking dates on the calendar
* Magit status
* Diff buffers (especially diff-buffer-with-file)
* Listing neighboring files with dired
* Notes on a code base/task in an Org mode fileFor reading anything of length, I like to split horizontally into three balanced windows [1], put the buffer in all of them, and `M-x follow-mode'. At that point, I get a nice columnar display that makes better use of the screen real estate.
If you do this, you can make paging snappier and more predictable like so:
(setf scroll-preserve-screen-position t)
(setf next-screen-context-lines 0)
---
[1] That is, three windows of the same size side-by-side.
> balanced windows [1]
> [1] That is, three windows of the same size side-by-side.
`C-x +` (M-x balance-windows) for those who don't know . There's also M-x balance-windows-area.
I usually have a vertical split, because it is useful to be able to refer to something else (e.g. other code, docs) while I work on my main task. I'll often have a pop up with a terminal or similar than I can bring up or dismiss with Doom shortcuts. That usually lives at the bottom. Occasionally three windows side by side is useful.
I cannot imagine using the features discussed in TFA though. They don't seem to solve anything for me.
Beyond the obvious answer (looking at two files at once, or a shell, or compilation buffer, or docs), I have a much simpler reason. My monitor is wide enough that if I have only one window, then all the text will be on the left end of the monitor, which means I'm constantly turning my head to work, leading to neck strain.
So even if I'm working on one thing, I do C-x 2 and use the right window, because then the beginning of the text is aligned to the center of my screen.
Yes, this is because I insist on running Emacs maximized.
I'd love to use more than one window, but they're completely unpredictable and really hard to configure the way you want. Magit buffers will open in one way, Cider Error buffers open in some other way. And the behavior will also change based on your frame size... You can sometimes configure them, but only from the limited behaviors provided by the package itself. The behaviors are different in different packages and there is no configuration/coordination in the "runtime"
There is a central configuration, see here https://news.ycombinator.com/item?id=43642743
Do you never refer to other files or documentation while working? Or use a REPL? Sometimes I even refer to the top and bottom of the same file simultaneously.
I only use C-x 1, C-x 2 and C-x 3, seems like that covers 95% of my use cases at least.
C-x 0 can also be useful.
Never used it, I tend to use C-x 1 to get back to one window; what's the difference?
No difference if you have two windows, but if you have three or more you just kill the current one giving the space to one of the adjacent windows.
I have more than a dozen special commands for splitting to multiple n*m windows filled with different types of buffers or transposing existing window splits; I occasionally need a split into 4x4 or 5x5 or even more windows to quickly/visually find the shell that logs something of interest to me. It is not neccessary, really, but occasionally helpful. I often switch between 1x3, 2x3, 2x4, or 2x2 layouts that it was worth putting in the time to organize all these splits and then adding some more felt easy and useful. My three different main monitors (home/work/laptop) often require different optimal splits and depending on the focus mode, fonts, or the presense of a browser window I may again need differnet splits. I often find it helpful to have follow mode on a 1x3 setup either a single document to have focus over a larger context. The main reason for all the splits, however, is managing several dozens of shells or code files.
I almost always have two side-by-side windows (C-x 3), usually when I'm writing a function I'll have the function on one side, and the other side is where I'm calling the function. So both windows change buffer constantly as I navigate a codebase.
I keep one window (in the common OS meaning of window) per virtual desktop and I usually split it into two horizontal buffers. Sometimes I split it in two vertical buffers, for comparing lines. Sometimes even in four, two rows and two columns per row. I can fit 55 lines into my emacs, plus the minibuffer, the status line above the minibuffer and the menu and title bar on top so even split in four buffers each of them is about the same size of the terminals I grew with. And I'm using proportional fonts, that are more readable and space efficient.
Depends on how you like to code. I have two full screen frames on their own monitors with 5 or 6 side-by-side windows, and a stack of three vertical split windows on one side.
I like to have the side-by-side windows looking at different files (unless I'm in a really long file) and the stack of windows have vcs, messages, and sometimes eglot
Well you could see multiple buffers on screen simultaneously, rather than just one? But if you don't want that, then there's no point. And anyway, the point of Emacs is that you can do what you like, and customize it to work well for you.
My most used is winner-mode. It's just undo / redo, doesn't provide any new logic, but allows to quickly goes back to the layout state before you maximized a buffer. Bound to S-b for winner-undo and S-n for winner-redo IIRC.
Two windows are invaluable when doing diff, ctrl-F2 to navigate both windows to the differences in both windows.
I can quickly go over the content of the files in a directory with one window in dired mode and another for visiting the files.
More than two is a bit painful, in my experience, as I don't think Emacs has directional focus like the usual X11 WMs (e.g. i3, bspwm) and C-o works well with only two.
Magit and sly/SLIME work much better with a second window, I'd say.
> I don't think Emacs has directional focus
It does, but I don't think they have default bindings. The commands are windmove-{left,down,up,right}. I've had them bound to C-S-{h,j,k,l} for years and it makes moving around much more fluid and predictable than C-x o.
If you need to manage multiple windows in emacs I find ace-window perfect.
Pops up a number in the top left of the window and you hit it to jump to it. If only two, C-o works as before.
https://github.com/abo-abo/ace-window
I have never used more than like 5 windows and only for a short time. I guess it doesn't work past 10 but that's gotta be enough for anyone...
Most of the time I have 4 or 6 buffers visible at once, including the REPL and files I’m editing - and that’s when I’m working on “one thing”, having packages like transpose frame or ace-window makes this type of workflow much easier
> I value mostly screen space dedicated to the one thing I am doing.
Sure, but that's like ... what? Half the screen in the best case scenario?
The other half is whitespace, so it makes sense to see the rest of that file in the other half.
For a while I used dired-sidebar-show-sidebar and dired-omit-mode to give me a list of files in a narrow window on the left. I kept messing it up with C-x 1, though.
I tend to use emacs from within screen(s), and use screen for the layout, but I think I might need to reconsider when 31 hits!
I have a 42" 4K TV I'm using as a monitor and need to split it into multiple windows to make effective use of it.
Just a comment in solidarity; I came here to ask the same question. :)
I think my big problem is: I need a native terminal program, and I'm almost always using a terminal for something while I'm using Emacs. Which means I can't dedicate a whole screen to Emacs.
Something to look at: https://www.masteringemacs.org/article/replacing-tmux-gnu-sc...
Oh, I know it can be done. I've tried to become an Eshell person, I really have. But I need a native terminal app.
I for one often split the window in two to have like an API definition and the implementation up at the same time, or to have a terminal and a script I'm running both visible, or such.
I’m confused, is this operating on Emacs’ frames or windows.
** For those here that are not Emacs users these terms mean the opposite of what you’re likely used to.
For those that don’t know. Emacs was there before windows managers was the norm (I think), so after splitting the emacs view, each part was called a window.
The whole view is called a frame and store the window layout. You can create as many frames as you, each with its own layout and in terminal mode, they would swap like i3 workspaces. But in graphic mode (GUI) they are what we call window today, what emacs users refer as windows would be panes.
It operates on frames, moving the windows inside them, similar to how transposing a matrix moves around the values it contains.
The joy of this is that emacs doesn't care if you have a desktop or if you're headless in a terminal. Which sounds a but morbid.
Any chance folks have pointers on how I could do this for the windows of my desktop? Running PopOS and would love to setup some keyboard macros to setup common window arrangements. I am embarrassed that I have basically no idea where to start in doing that, though. :( Would I be looking to do a Gnome plugin?
Sway/i3/etc?
Do I really have to jump to a new compositor/window manager to get this? Seems like I should be able to query the state of my desktop without doing that. :(
In theory if GNOME exposes enough API surface then sure you can write a plugin to do it. I'm rather under the impression that GNOME is not particularly friendly to that kind of customization work, though. Perhaps it's better these days; I haven't paid it as much attention since jumping ship. It is entirely possible that it would be less overall work to switch to a window manager that enthusiastically exposes all the API surface you could ever ask for, but don't let that stop you from looking into it.
:D Completely fair answers!
I don't know why it is so surprising to me that there isn't a very easy "list windows and locations" in computers. Feels like something that should be as a basic building block, but I have never seen it. Assumed I just didn't know where to look.
Thanks!
Oh, this will be nice. I've had a home-grown (rotate-windows) function in my config for a long time. I love it when I can shrink my config because core now has an equivalent.
I once created a custom function that toggles between vertical and horizontal splits of two windows. It’s quite handy. https://github.com/masutaka/dotfiles-public/blob/66c976fb069...
I am on macOS with a split screen browser left and emacs in the right half. Max 2 window vertical split in that frame and if needed a C-x 5 2 which opens a full screen frame workspace to the right for a c-x 3 side by side layout. That’s it - all the other buffers are backstage partying until they get called.
This is great! I often have a situation where I have a nice three pane split with one split vertically and another one horizontal in one of the vertical panes, but if I close the big vertical pane, I now just have two wide horizontal panes and have to recreate the layout.
These functions are far more useful than I would have expected them to be. Will have to find a way to add them to my muscle memory. Curious if there are any obvious keybindings people have started using for them?
I added `C-M-0` for flip and `C-M-=` for rotate, so far liking it.
Oddly, I think '0' (or 'O') may make more sense for rotate? With '=' good for horizontal flip and '|' good for vertical flip? I'm probably trying to force more meaning in the character than makes sense. :(
I will say that these are immediately useful when any of the automatic splits picked the wrong "side" from what I wanted. Really really useful.
Oh this makes me quite happy! I’ve been using an awful hack to do horizontal-mirroring (that sometimes borks), I’m so glad to find there’ll be a better way. Massive props to the author!
I've gravitated to the use of a 43" 4K TV as my main monitor (and have a few others scattered about for auxiliary purposes) and when hacking hard have a full screen emacs window split into lots of panes, vertically and horizontally a la Mondrian. I am confused about how others get anything done without a similar configuration! This new feature seems like it will be great fun.
Oh yeah, and I generally keep such a monster running in a GNU screen via mosh on servers too. Loverly! They can run for years.
nice ! i typically use windmove.el for all windowing needs within Emacs including (but not limited to) moving between windows, swapping buffers etc. etc.
Neat, I've been using this for a while. Happy to strike off yet another package.