Re: Infrastructural complexity.

[martin rudalics]

>> Did anyone ever specify what the "useful sense" of saving a frame
>> configuration is?
>
> I guess "useful" means an ability to restore a frame configuration
> to the state that was before saving.

Sure.  But what goes into a frame configuration?  Overlays?

> I misread this task as "a feature to switch between different named
> frame configurations" that makes sense for the current discussion.

IIUC desktop only affects what Emacs does when starting a session.  Or
am I wrong?

> ECB layouts are too specific to the code browser and can't be used
> stand-alone that would be a useful feature.  But there are many good
> ideas in ECB.  It uses procedural definitions for layouts like:
>
> (ecb-layout-define "left1" left
>   (ecb-set-directories-buffer)
>   (ecb-split-ver 0.3)
>   (ecb-set-sources-buffer)
>   (ecb-split-ver 0.5)
>   (ecb-set-methods-buffer)
>   (select-window (previous-window))
>   (ecb-split-hor 0.5)
>   (ecb-set-history-buffer)
>   (select-window (next-window (next-window))))
>
> Such procedural definitions insure that created and restored
> window trees will be the same.

IIRC ECB records the entire history of window changes for saving such
procedural definitions.

> Maybe desktop.el should try
> saving window trees with similar procedural structures where
> content of each restored window will be filled with either
> a file or the result of `desktop-buffer-mode-handlers'.
> I mean replacing `ecb-set-directories-buffer', `ecb-set-sources-buffer',
> `ecb-set-methods-buffer' in the example above with a single call
> to `desktop-create-buffer'.

I'm afraid that we have to use a "procedural" instead of an internal
object like `set-window-configuration' does.  Otherwise, we risk
crashing Emacs when a user stores a "non-procedural" configuration on
file and deliberately changes it.  However, I profoundly dislike
procedural specifications for saving states :-(

martin