I was wondering if there is a way to mark certain frames in a split window emacs session as inviolate to changing. I normally have 4 frames for sources files and 2-3 frames for other views such as compilation/grep-find/etc.
I would like to mark the latter frames somehow so that they will never be split or have their contents changed by emacs. This way if I click on a search result I don't have my compilation window splitting and a source file inserted.
I want any source files to go in my source windows and to stay out of my misc-view windows.
Is there a way to do this?
|
| |||
|
feedback
|
|
Yes, there is a way to do this, but I don't think it will be easy. A quick look through frame-related functions and variables confirmed my belief that there's no easy fix here. The problem is that Emacs would not know what to do once these frames are the only remaining frames, and something needed to be done to/with them. I think it would be possible to code up a package that advised all of the low-level frame manipulation functions such that some frames would remain untouched by any operation, but that would require identifying and interpreting each of those low-level functions. I think a better approach (unless you're an elisp wizard) would be to identify the functions that you use that annoy you in this manner, and see if there's a common function or group of functions that they use to determine which frame to display their output in, and then set out to change that behavior. I would probably use a frame parameter ( You could also have several classes of frames (e.g. source frame, compilation/errors frame) and allow some of these to be re-used by certain functions but not others. How complex you make it, really, is up to you and your imagination. Anyhow, it looks at first blush to be very doable but non-trivial. Now, having said all of that, there is a package out there that may help you get closer to what you want: One-on-One Emacs. It don't know if it protects frames the way you want to, though. And from the description it seems like it re-defines a lot of core functions, rather than advising them, which could make it extremely version-specific (that's just a feeling I got reading his description; I didn't look at the code to see if that is what actually is happening). Good luck! | |||||||||
feedback
|
|
One option could be looking into how gdb-many-windows works - this mode is very aggressive about preserving a specific window layout. Also, it is possible to save a frame / window configuration to a register, and to retrieve that configuration from the register later. Third option: here is a solution in elisp (you could just evaluate it in the scratch buffer to try it, and add it to your .emacs if you like it)
| |||
feedback
|