stack-order (z-order) parameter for frames [was: Add function to make frame topmost?]

[Drew Adams]

(Changed the subject line, so as not to interfere with the `topmost'
discussion.)

> Restoring the relative z-order of emacs frames, but restoring them
> contiguous in the stack and maybe at the top (not always-on-top,
> I just mean in front) on restoration, might be a better option. 

That is what I meant: record and restore the relative z-order of Emacs frames
(not of all window-mgr windows), and restore them contiguously in the overall
window-mgr stack. IOW, restore Emacs frames as they were, as much as possible,
including wrt their relative z-order.

> Except when the user is saving and restoring in rapid succession
> in the one session, as I imagine most people's typical use of 
> frame-configuration-to-register/jump-to-register is. Then it might be 
> the surprising/annoyingly-raisey option, and leaving
> the z-order as-is might be best.

Yes, I was referring to persistent save, and restoration from a persistent
record. My bringing this up here was meant to be in the context of the
discussion about persistently saving/restoring frames and frame configs.

However, I would like to see each frame have a frame parameter that records -
and hopefully controls (as much as is possible), its z-order. That's independent
of persistent save/restore.

Use of such a parameter could be to raise/lower individual frames (e.g.
incrementally, by users), and that would be relative to other _Emacs_ frames,
certainly. We could also perhaps let it be used optionally (under Lisp control),
to raise/lower relative to non-Emacs window-mgr windows (e.g. move a frame
topmost among all window-mgr windows).

In addition, the frame parameter would be used by persistent save of frame
configs and their restoration. IOW, the same frame parameter would be used for
both (a) live control (checking where a frame is in the stack and moving it
up/down the stack) and (b) save/restore of frame configs.

For restoration of a frame config, the Lisp code in question would know whether
or not it is restoring from a persistent store, and it could decide whether or
not to respect the `z-order' parameter. No hard-and-fast rule about that should
be hard-coded into the frame-config representation or the basic frame-config
save/restore code. As much control as possible should be available to Emacs-Lisp
code.