Re: Freezing frameset-restore

[Stefan Monnier]

> Eh, no.  As I said already, processing the frames in random (maphash)
> order just isn't going to cut it if you want to delete frames.

Ah, then we need to fix the docstring and specify that the order of
elements in the returned list is not arbitrary but provides some kind of
guarantee (which we need to describe).  Yuck.

> That would be an argument to split every long function along its
> length, just by looking for appropriate places where it can be
> "cleanly" done,

Indeed, it is.

> but that's not an argument that I can accept.
> Restoring a frameset is going from one frame configuration to another
> one; cleanup isn't just something that gets accidentally done
> afterwards.

And starting a new process is "one operation" but some people think it's
much cleaner to do it as a bunch of simple syscalls rather than as one
giant can-do-anything monster.

Yes, every caller of frame-restore will probably want to cleanup
afterwards, but that doesn't mean we should provide "one function that
does it all".

>> Personally, I'd just ditch frameset-restore-cleanup.
> I'd ditch it too, for a CLEANUP arg to frameset-restore.

OK, but then make it very simple: it should be a function that takes
a frame and a symbol (the action that was taken on that frame) and its
return value is ignored.

> You can create an invisible frame, save it in a frameset, then delete
> it (so you have just one frame, visible), and then restore the
> frameset over your only frame.

But your frameset has 2 frames, so after restoration you should also
have 2 frames, no?


        Stefan