Minimizing a window might free a little memory, but it depends on the application, and it won't amount to much. In any case, minimizing won't make more difference than any other form of hiding.
Even if an application's window is minimized, it's still running. The application isn't going to need to keep less data in memory just because one of its windows is minimized.
An application is notified whenever one of its windows is minimized or restored. It's also notified whenever part of its window becomes visible or hidden. It is possible, but unlikely, that the application would react differently to various reasons its window may be hidden:
- It can be minimized, meaning the window is not shown and an icon is shown in its place.
- It can be hidden behind other windows (including the full-screen window of a screensaver).
- It can be displayed on a different desktop, workspace, viewport, or whatever your window manager calls these.
- It can be hidden in some other manner, for example “shaded” (meaning only a title bar is shown), or simply unmapped (meaning the window manager has decided for whatever reason that the window shouldn't be displayed).
If an application's window is completely hidden, then the application doesn't need to refresh the window contents. If it needs to allocate memory to refresh that content, it won't be doing it while the window is hidden. Also, if a window is hidden (for any reason), the application might free a little memory inside the X server.
What makes more of a difference in practice is that if a window isn't being displayed, then the application doesn't make computations to redraw the contents, and therefore the data needed to draw the contents can be swapped out. If RAM is tight and there's a window you aren't going to iteract with for a while, it's better if the window is not mapped. Again, the reason why the window is not mapped (hidden behind others, minimized, shaded, …) is unimportant.
I am glad to see another ratpoison user. Let me tell you that I am a happy and satisfied ratpoison user and can not think of another window manager right now. It has increased my speed and productivity multiple times.
Now coming to your problem. The key conflicting part you can handle by pressing the key again after pressing the escape keycombination. e.g. I have my escape keybinding as Ctrl-a. Now if I want to select all the text or want to send cursor at the starting of line in bash I, have to press Ctrl-a then only a again after releasing escape keybinding.
For your other queries I need to do some reading.
Best Answer
Background a process in subshell #1 and get it back to foreground on subshell #2 is not possible at all (if you don't use extra tools like: reptyr).
In your case you even did not start it from terminal and
Ctrl+Zhas a different behavior if you are not in a terminal. I think yourCtrl+Zis doing some other "magic", ratpoison-default-keybindings even do not list it. Maybe you should figure out, whatCtrl+Zis bound to on your setup.EDIT
From Emacs Manual:
You should just be able to
Alt+Tabthrough open applications to emacs. Maybe under ratpoison there is another way to get back minimized frames. Or addAlt-Tabto ratpoison, edit your.ratpoisonrc:and restart rp.