Re: Freezing frameset-restore

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> Right.  But we're simplifying the "interface".
> Hm.  On one hand, the interface is already complex; on the other hand,
> it's not more complex than make-network-process or defcustom ;-)

The fact that it's bad already or that there's worse out there is no excuse.

>> And we can provide a frameset-restore-cleanup function which does the
>> default thing.
> I don't understand what you mean, i.e, a function for the common case?

Right (I'd expect that function to take the whole list, BTW, but
if mapc can be used, it's not critical).

Of course, with only 2 users so far, it might be tricky to decide what
is "common".

> I'm not sure we gain anything with this. As a net loss, we must
> construct (and sort)

I don't see why sorting would be needed.

> the return list even if it is not going to be used, while in the
> CLEANUP argument case, no list is constructed; in fact, if CLEANUP
> = :keep, not even (frame-list) is called at that point.

Clearly, the returned list does not need to give an action for
all frames.  Only for those which we did consider.  So we don't need to
call `frames-list' just so as to build the return value.

> that many; it is a specialized feature anyway, and its main use case
> (and the reason it was implemented) is already covered by desktop.el.

Exactly.

> I don't find it terrible, but neither do I find it cleaner.  Anyway,
> it's your call.

I think it's cleaner.


        Stefan