planned screen(1)-based workflow

I now have 3-6+ virtual desktops, each populated with 3-4 xterm windows, plain zsh running in each of them. What I want is to limit my console work to one virtual desktop with 4 xterm windows all directly connected to a single local screen session. Every command I run should start in a new window, and screen should switch to it immediately. When the command finishes, the window should be killed and screen should switch to the last window I was in, so that execution of short-lived programs looks exactly like no new windows were started at all.

There should be window groups and I should be able to switch to another group, effecting every xterm window, with a single keypress, emulating multiple virtual desktops with 4xN xterms.

Basically each window should be fully logged with some security-wise exceptions.

I hope to thus reduce RAM usage dramatically. Keeping long-lived non-daemonized processes in separate windows should save me from wasting another xterm+zsh. I can set xterm's buffers to a small value and 4 xterms are not too fat a load compared to 10-20. The number of zsh sessions will not decrease much, but I'm looking at zsh built-in (or plugged-in) solutions which can help me improve my shell/console experience.

What I would really appreciate is 4 xterm windows and 1 zsh session, full emulation of unlimited xterm+zsh windows. How's that possible? Well, I only have two hands, so I'm only truly interactive in one window at each point in time, so zsh really needs only one stdin from me. When I start programs, zsh should run them in the background and reassign stdin to them. Or something like a single zsh server managing cache and jobs and lightweight clients.

Actually, I can imagine how I can make that happen. BTW, I might settle for two rxvt windows (display split in two by a vertical border) and have screen split each one in two or more by horizontal borders. I know screen can be patched to have vertical internal borders, and I know that different ways to move left-right and up-down can slow me down, but I'm willing to try, I think, and with the large resident footprint of all-included rxvt-unicode it's always nice to cut down on the number of separate windows. So. I need some kick-ass wrappers. Basically, if zsh itself (with all jobs in the backround or none running at all) is visible in several places on screen, only one of the places should accept any input and produce any output. These zsh-windows can be implemented in several ways. There's only one active zsh-window at any time. The easy logic to select a new active zsh-window can be based on keyboard input - i.e. whichever zsh-window receives input becomes active immediately. Saving/restoring states of zsh-windows crossing active-nonactive states with non-empty input buffers can be very difficult. It probably should be implementation-defined.

Off-hand, I'd say these zsh-windows can be implemented through lightweight sh or C wrappers, or using zsh modules for output on multiple TTY's. The real solution is probably to write a zsh module, but that can take time.

Another nice feature would be survival of reboots to some extent. Processes like zsh and top should be restarted. Programs like vim should be restarted with restore options. Copy buffers should be restored (by replaying window logs?)

Layers of key-bindings

Only now do I recognize how many layers of key-bindings I have to keep in mind at all times...

• xorg
• wmii
• rxvt
• screen
• zsh
• applications

Xmodmap

"Please release the following keysum in 2 seconds" - says xmodmap from time to time when I try to rebind Caps Lock to Mod4 (I use it as the MOD key in wmii). "sleep 2" helps, but I'll have to read xmodmap's code to learn why bother. Or maybe it's worked arouned in X.org 7.x somehow.

Screen

Much as it is vital, screen is a real pita to configure right. If I start it in a text-based console terminal and then reattach in rxvt, control sequences (like Backspace and Home) get totally crazy. And that's just one issue of a thousand. Lot's of work is to be done.