Re: Freezing frameset-restore

[Juanma Barranquero]

On Mon, Mar 10, 2014 at 9:32 PM, Stefan Monnier
<address@hidden> wrote:

> 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.

I'll add that to the appropriate place, once we agree about it.

> 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".

If you excuse my analogy, it's like changing a flat tyre. Of course it
can be divided into removing the old one, and putting the new one.
Other than a bit of sharing (the jack carries over from the first
operation to the second), they are separate operations. Yet no one
thinks of it that way because the user experience is "fixing the tyre
so the car can go again".

You think of frameset restoration like two operations: 1) restoring
frames, and 2) cleaning up frames. But frameset-restore is just one
operation: going from a frame configuration in your display(s) to
another, different one. 2) is as part of it as 1), and in most cases
(certainly, in *our* use cases) it is a non-null operation.

> 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.

Currently (in my last patch), it's just that, plus the options t and
nil to simplify common use cases. Do you want me to remove the t/nil
options?

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

If you're doing it via desktop.el, yes. But you can save a frameset
from a partial set of the current frames. And just in case you think
it's too artificial, I discovered the problem because it happened to
me (though I don't remember what was I doing at the time). And even if
you are saving the full frame list with desktop.el, if you switch
displays or something like that you can end restoring less frames than
originally saved, so it can definitely happen. It's better to protect
against the case, however unlikely, that present the user with an
invisible running Emacs.

    J