Is there a reason to use frames over windows

So from my understanding as someone still relatively new to emacs frames function about the same as windows with the biggest difference being frames position is managed by your os rather then emacs itself this means commands such as C-x o don’t work instead i would have to do C-x 5 o and it usually doesn’t seem to integrate as well from my experience is there a feature of frames that im missing that would make it more useful the only one i can thing of is i can move the frames around with my twm but emacs handles this well enough

You can have them on multiple monitors. On regular window managers they can overlap, and you can switch between them. Useful for working on multiple projects, each in own frame

The multi monitor part seems really nice for people who have multi monitors but I don’t have one or plan to get one so it doesn’t matter to me and doesn’t emacs also have that second part built in with tabs I haven’t used tabs before in emacs but still

[deleted]

I mostly only use them for multiple monitors. I have it bound to super key f (\`s-f\`?) so it's easy for me to access. Sometimes it's also nice to have my compilation buffer in there. No problem with not using it. It's just another tool in emacs that you can use if you want, but windows are plenty powerful if you only have a single monitor.

Perhaps multiple workspaces on the same monitor then?

I really like eyebrowse for this: [https://depp.brause.cc/eyebrowse/](https://depp.brause.cc/eyebrowse/) ​ Not sure if this usage is completely covered by the new tab functionality tho.

The key thing to us grok is that there's always at least one frame. You can have multiple windows in that frame. And you can access any buffer in any window in any frame. This becomes particularly useful if you use the GUI and `emacsclient`, because then every GUI or TUI shares the same buffers. So the files in the terminal are the same as the GUI. And if you create a new frame, it's still the same set of buffers available.

Frames keep your window configuration intact. Suppose you are reading email using Gnus or any other email client. And one window keeps list of mails and another window showing one mail. Now suppose you want to switch context in the middle of reading email. In this situation I don’t want to loose the layout where I am reading email. So I either use frames or tabs. Yes both are same unless you are using multiple monitors. There is another way to achieve this if you still don’t want to use frames or tabs. You can save window configuration in registers. And later restore them. The advantage of using frames and tabs is that you can save them using desktop-save command. And restore in another emacs session using desktop-read. Registers are not saved using desktop-save.

You can have a frame on another monitor. But apart from that, I don't really see much benefit in using multiple frames on one monitor.

If you have two Emacs frames and a browser window, you can place one Emacs and the browser side-by-side^(\*). If you have a single Emacs frame with two windows and a browser, you can place them side-by-side, but both Emacs windows will be visible, which may hinder buffer content visibility. ^(\*) Side-by-side placement is viable on 24″ or larger screens (assuming eye–screen distance of one standard arm’s length).

It depends a bit whether you use the emacs server. If not, then each frame is a new instance of Emacs. In other words, a change in config in one frame does not impact the other frame. If you use the Emacs server, then all frames have the same configuration. Frames are only useful when running multiple configurations or using multiple monitors.

Yes, I already have a tiling WM and I don't need another one with a different set of keys (I'm not using C-x 5 0). I have super-e mapped to run emacsclient.

I don’t personally use my twm for much basically just for switching workspaces swapping windows and launching apps that personally doesn’t matter much to me

isn’t all of that true for windows tho?

Well yea, managing windows is what a wm does, including the one built in to emacs. I prefer to use the same one at all times.

It’s personal preference. I use emacs on a 27” iMac, in GUI only, with typically one portrait oriented frame allowing me to see other apps on half the screen (I rarely use full screen mode). Typically I have one window in the frame, often two windows, one above the other. I use a dedicated portrait frame for gnu and another for info. It’s great when I use those that they pop up, I can orient them, give them a different default frame font and close them when done with that activity without affecting anything else. Sometimes I open another frame to read a regular buffer and have it side-by-side with my main frame. I’ve mapped the C-x 5 prefix to C-z. It’s nice that I can use C-x o to switch between windows in my current frame or C-z o to always go directly to the current window in the other frame (I know about ace-window which is also good, but I often find this faster). It’s also nice that my gnus frame is positioned in the center of the screen while the others are positioned to one side; because if I’m reading gnus that’s all I’m doing, and if I’m using others, I’m often referring to things in the different frames.

I use i3 and emacs is very well integrated in my workflow because I mostly use frames. I can also navigate through emacs windows by using super+hjkl. I have super-w for all xorg clients and I have super-e for emacs buffers. When I select a buffer I get that buffer in a new frame. I have reserved ctrl+space as a i3 emacs prefix key and space as a emacs prefix key. This way I use the same shortcuts and same mnemonics. The only thing I need to remember is that I need ctrl when the emacs buffer does not have the focus, because in that case I am on i3 level. Basically, I get an i3 variant of EXWM. Better window management and emacs is fully integrated. It works very well because most of my needs are satisfied by emacs. For the process management i use proced and the shortcut from i3 is: ctrl+space e >> activates emacs mode then p activates: emacsclient -c -e "(proced)" ctrl+space d >> activates: emacsclient -c -e "(dired)" Etc. I have i3 modes for emacs, org, notes, projectile, etc. It is simply amazing! Because with the same set of shortcuts I seamlessly switch between xorg clients and emacs buffers. They are all i3 clients because all of my buffers are emacs frames. Occasionally, I have two windows in the emacs frame, but I can easily navigate with super+hjkl between them the same way I navigate to other i3 clients. Of course I run emacs as a server for all of this and I need both i3 and emacs running together to have this integration.

I personally prefer just one Emacs frame, and just to work with windows. I dislike "alt-tabbing" and switching between top level windows, so that is one of reasons why I prefer to integrate as much of my workflow as possible in Emacs. Running Emacs in multiple frames would be counterproductive in that regard. Less switching and manipulating the workplace, the more time to do something useful, not that I actually do as much useful everyday, but the thought is there 😀.

> Frames keep your window configuration intact. Came here to say this.

Yeah, I've not used tabs either. Though switching tabs would be an extra step when im already switching between firefox, emacs, slack, etc

1. Pretty much any two different things present different use-cases or advantages. So the answer to "is there a reason" (or are there reasons) is clearly yes. 2. Emacs frames are akin to (and ~implemented as) window-manager windows. * Do you use multiple window-manager "windows"? If so, why? Same for Emacs frames (at *least*). * Or do you prefer to be limited to only one such window, IOW, to be limited to only a tiling window manager? If so, then maybe you won't see any advantage (use case) for Emacs frames.

Eh yes i think i use it so i can copy stuff between windows mostly and so i can view documentation while im doing something and I don’t find having just one window opened to be in anyway limiting

The biggest issue I had with frames was that the various project/perspective/... packages could not handle the existence of multiple frames. They would always get confused, probably because the developers only used a single frame with never more than one project open at a time. I used to work on two related projects and had to switch back and forth so often that I tried to have a dedicated full-screen frame for each. It never worked, though. That was a few years ago. Maybe I should give it a fresh attempt.

Not in the sense that they meant it, no. If you use emacsclient to open a new “way to interact with emacs”, whether it be on a local display, a console, or a remote display, those are all separate frames. None of those are ‘required’, of course, and maybe you never want to do those things, but some people do.

This, plus there’s another option that I like: my browser window is wider than my usual editing-code-or-prose emacs frame, **and** I have another emacs frame that’s the same size as my browser window, with larger fonts (set-frame-font), for times when I want to read things in emacs rather than the browser — which is pretty often, given how visually junky many modern web sites are these days. With a separate frame, I can have a large, proportional font emacs frame under/over my browser window, and still keep my editing/note-taking/shell/etc emacs frame separate. This sort of thing is either much harder or not possible with a large emacs frame and multiple windows (depending on your window manager/OS).

I meant having multiple frames at the same time I don’t see a point in that you can’t use emacs without at least one frame

I was talking about using multiple frames, but also, you can quite easily close all of emacs' frames, then reconnect later to that same emacs, with all its attendant state, and open new frames. In fact, you can open up the new frames from other computers, or from the console even if started in a gui session, etc. This is the basis for --daemon and emacs-server.

What is emacs-server i have heard of the daemon but not emacs-server

Same thing

Apart from all the other things people have mentioned, there is of course also multiple instances. I have one instance of emacs for email and org-mode which obviously presents its own frame. Then I have another instance which emacsclient with connect to for regular edits. This results in multiple frames but that's because of using 10 virtual desktops, so the frame should show on the desktop where it is used/needed/launched. And lastly for development, I will launch a new emacs instance (no daemon) inside the directory of the project so that it inherits the relevant environment. All of this separation is just to avoid having \*everything\* come crashing down when emacs encounters an email it doesn't like and needs to be force-restarted.

> There is another way to achieve this if you still don’t want to use frames or tabs. You can save window configuration in registers. And later restore them. Saving a window configuration to a register includes saving the location of point in each window, and when you jump to the register the point in each window is restored too. I find that is almost never what I want and often use tabs or frames just to avoid point being restored to a long-ago and now irrelevant location.

Probably that is why the registers are not serialised using desktop-save. After a long time we don’t want that.

The emacs server (via the server-start function and the command-line emacsclient program) are long-standing features that let users interact with an already-running emacs, dating back to the days when one would set $EDITOR to emacsclient and use job control to multiplex a single terminal session. Daemon mode in an enhancement that tells emacs, roughly, “start up using a dummy placeholder frame (less capable than either gui or tty frame), start emacs-server, and wait for further instruction”. Emacsclient gained the -c switch to open client frames (and -nw to open tty frames, since there was now another choice), and now you can mix and match both. (Sadly, nobody has ever taken the time to add macOS frames, neither ns- nor carbon-port, to that mix, it it’s conceptually possible.)

This is smart. I'm going to try this idea out and make a separate process for running org-agenda and chronos in. I've already done it in the past for exwm, so not sure why it didn't occur to me to do it for more sane reasons.